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PREFACE 


Skylab was the most comprehensive manned space program completed 
to date, involving unprecedented numbers of experiments, government 
agencies, contractors and supporting personnel. Ninety-four experiments, 
plus several experimental operational instruments and twenty-six science 
demonstrations, were developed, integrated with Skylab, and flown. A 
majority of these were individual experiments, although some (e,g., 
earth resources and space materials processing experiments) were associ- 
ated with discipline-oriented facilities provided for scientific users 
by Skylab. Experiment data gathered aboard Skylab was supplied to over 
two hundred and fifty scientists from the United States and nineteen 
other countries. 

The many interfaces involved in the development and integration 
of these experiments Imposed new burdens upon the "standard" methods 
and techniques that had evolved from earlier space programs. As a 
result, many changes were made, and many lessons learned, throughout 
the course of the Skylab Program. For example, new types of documen- 
tation were established, design review and configuration management 
techniques were improved and mission support activities took on new 
dimensions. This Experimenters' Reference records the Skylab experience 
in experiment management, including lessons learned and recommendations 
for improved cost-effectiveness, to facilitate the transfer of this 
knowledge to experimenters in future manned space programs. 
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DEFINITIONS 


Acceptance - An official act by the Experiment Development Center to 
accept transfer of accountability, title, and delivery of an end- item 
of hardware or software, whether procured on contract or in-house. 

Acceptance Test - The formal assessment or testing accomplished in 
accordance with Part II of an end item specification to verify the 
performance, configuration, and manufacture of an end item (1) at the 
time of its delivery and acceptance by the Government, or (2) for 
delivery to another NASA Center. 

Activation - The activities associated with originally placing an 
orbital vehicle or ground facility in operational condition. 

Baseline - An approved and defined technical description providing a 
point of departure for control of future changes. 

Clus ter - The orbital assembly constituting the complete configuration 
for manned Skylab missions, including all modules of the unmanned 
laboratory plus a docked Command and Service Module. 

Crew Compartment Fit and Function (C^ 2 ) ' - 'One of the 'final check- 
outs performed during hardware integration. Flight crew members in- 
spect the carrier for proper hardware integration, accessibility, and 
safety considerations. 

Delivery - The physical transfer of hardware from one site to another. 
Includes transfer of responsibility for hardware custodianship (also 
see Acceptance). 

End Item - An article of hardware or software which is deliverable by 
NASA or a contractor as a complete item as identified, defined and 
scheduled . 

Experiment - A part of the payload devoted to the investigation of 
scientific or engineering phenomena. Sometimes used as synonymous 
with instrument; however, instrument generally refers only to the 
operating flight hardware, whereas experiment refers to the combina- 
tion of all associated hardware plus the use of the data to satisfy an 
objective. 

Ground Suppor t Equipment - Special equipment required for-servicing, L" 
testing, handling,,, maintaining', and/or transporting-. the experiment - 
hardware during ground operations. 
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High-Fidelity Mockup - Training hardware that is essentially identical 
to flight hardware in size, shape, and appearance and provides crew 
interfaces (switches, etc.) but need not be operational. 

Instrument - An item of hardware designed to perform a specific scientific 
or engineering function in support of an experiment objective (also see 
Experiment) . 

Interface - A region common to two or more elements, systems, projects 
or programs and characterized by mutual physical, functional, environ- 
mental, operational, and/or procedural properties. 

Integration - Activities that are performed to assure physical and 
functional compatibility of an experiment with other experiments, the 
module, and the overall mission. Also the physical mating and testing 
of a combined system (e.g. module and experiments). 

Mission - A single spaceflight from launch to landing, and Its objectives. 

Module - A major element of the payload or spacecraft, which carries 
experiments and support systems designed to meet mission objectives. 

Near- Real Time - A short period of time, (normally within 24 hours) 
after actual occurrence of a mission event. 

Open Item - A question or problem which is unresolved, and requires 
action to ensure its resolution. 

Orbital Facility - A group of instruments designed to investigate vari- 
ous parameters of a common subject or discipline. 

Qualification - Determination that an article or material Is capable 
of meeting all design and performance requirements established for the 
item. An item can be qualified by test, by analysis, or by similarity 
to a qualified item. 

Single Failure Point - A single Item of hardware having an independent fail- 
ure mode which would result in the functional loss of a system. Examples 
are nonredundant valves, regulators, pumps, motors, switches, relays, 
transistors, resistors, diodes, or a single path of passive electrical 
hardware (e.g., wiring, solder joint, connectors, etc.) that could open or 
short circuit. 

Waiver - A written authorization to accept an end* item or other designated 
item which, during manufacture or after having been submitted for inspec- 
tion, is found to depart from specified requirements but is considered 
suitable for use "as is" or after rework by an approved method. 
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SECTION I. INTRODUCTION 


A, Purpose 

This document is intended to familiarize prospective partici- 
pants in future manned space programs with the methods and techniques 
for experiment development and integration that evolved during the 
Skylab Program, Future programs may not adopt Identical procedures, 
but insight into the Skylab experience, including the lessons learned, 
will be of value as a reference for scientific investigators, experi- 
ment developers, and integrators who face similar tasks in the future, 

B, Scope 

The Experimenter's Reference outlines the full spectrum of 
experiment-related responsibilities, activities and events as they 
were planned and executed in the Skylab Program, The planning and 
the execution sometimes varied; exceptions and variations were common 
as the program developed. This is not a history of such deviations, 
but rather a compilation of those methods and techniques which experi- 
ence proved to be most effective for Skylab. 

The major activities and events that involve experiments, and 
their Interrelationships, are illustrated in functional flow charts 
for the overall program and for each of its major phases. An over- 
view is given of the National Aeronautics and Space Administration 
(NASA) management roles and responsibilities. The alternative 
approaches of providing single experiments for individual investiga- 
tors, versus a multi-instrument orbital facility with many "users," 
are discussed. The evolution of the experiment and Its hardware, 
and their integration with Skylab, are traced from initial concept 
through delivery, integration testing, mission operations, data analy- 
sis and reports. Configuration control and the influence of special 
disciplines (safety, reliability, maintainability, quality assurance 
etc.) are separately treated. Public relations aspects are also 
discussed. Skylab lessons learned are incorporated in the form of 
specific "Recommendations", interspersed at appropriate points through- 
out the text. (Additional lessons learned across all program discip- 
lines, as compiled by NASA Headquarters and the various NASA centers, 
may be found in References 1 through 4.) 

The main text is intentionally concise. Additional details, 
where considered appropriate, are provided in separate appendices. 

For example, major experiment-related documents referred to through- 
out the text are described in detail In Appendix A« 



C. Program General Flow 


The general functional flow of activities and events that 
involved an experiment followed a fairly standardized pattern 
(figure 1), whether for an individual experiment or for an instrument 
forming part of a facility. Distinct program phases, as identified 
in figure 1, are amplified in sections III through VIII; activities 
which extended through many phases of the program are discussed 
separately in sections II and IX through XI and in Appendix B. A 
second-level flow for each major program phase is included at the 
beginning of the applicable section to illustrate the relationships 
of activities discussed within that section. A "waterfall" chart of 
experiment program elements (figure 2) depicts the overall Skylab 
experiment program in greater detail. 
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SECTION II. PROGRAM MANAGEMENT 


In general, management systems and techniques employed by NASA for 
the Sky lab Program were outgrowths from those developed on previous man- 
ned space programs. They naturally evolved and changed during Skylab; 
further variations can be anticipated to accommodate the unique require- 
ments of future programs. In recognition of this fact, an effort has 
been made to Identify the necessary management functions in a general 
way, regardless of who may be assigned to carry them out. 

The areas of general responsibility for a space experiment pro- 
gram are: 1) program direction, 2) hardware development, 3) integration, 
4) launch operations, 5) mission operations, and 6) analysis and report- 
ing. For Skylab, NASA Headquarters retained the program direction respon- 
sibility, and delegated the other roles to Individual NASA centers. 

RECOMMENDATION: At the outset of a program, publish and 

enforce clearly defined intercenter and intracenter author- 
ities and responsibilities for all program elements. 

A. Program Direction 

NASA Headquarters provided the initial planning and the top-level 
direction for all program aspects. A Headquarters Program Office (the 
Skylab Program Director and a limited staff) exercised this management 
role by means of guidelines and directives to the NASA Center Program 
Managers, and overall control of funds and schedules. Major decisions 
involving program and mission objectives, experiment selections and 
flight assignments, funding, and milestone schedules were made by Head- 
quarters, with due consideration for inputs from the appropriate centers. 

Various offices at Headquarters served as Sponsoring Program Offices 
(SPO) for individual Skylab experiments (see Section III B). A Manned 
Space Flight Experiments Board (MS FEB), composed of representatives of 
various NASA and Department of Defense organizations, performed a con- 
tinuing advisory function for the Associate Administrator for Manned 
Space Flight, relative to major experiment decisions. (MSFEB qgyered not 
only Skylab, but all current and contemplated manned space flight exper- 
iment programs . ) 


B. Hardware Development Centers 

Each major group of associated hardware end items (e.g., an ex- 
periment or module) r was assigned to an appropriate NASA center for 
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development. Any existing center could be selected, depending on the 
nature of the end items and center capabilities. 

1, Experiment Development Center . The Experiment Development 
Center (EDC) was responsible for management of the design, development, 
testing, fabrication, qualification and delivery of the basic instrument, 
supporting hardware and experiment-peculiar ground support equipment (GSE) . 
Following delivery, the EDC monitored experiment performance and provided 
technical consultation to the module development and operational centers 
throughout postacceptance testing and mission operations. In many cases 
the EDC utilized a development contractor to augment its capabilities. 

The organization (government or contractor) that actually produced the 
experiment hardware was referred to as the Experiment Developer (ED). 

EDCs for Skylab experiments included: George C. Marshall Space Flight 

Center (MSFC), Lyndon B. Johnson Space Center (JSC), Ames Research 
Center (ARC), and Langley Research Center (LaRC) . Other government 
agencies, Including the Department of Transportation, the United States 
Air Force, and the Naval Research Laboratory, performed the EDC functions 
for certain experiments. Specific NASA centers were assigned to work 
with these organizations, acting as "proxy" EDCs to eliminate any 
potential difficulties due to management and reporting technique varia- 
tions utilized by different government agencies. 

2. Module Development Center . The Module Development Center 
had the same responsibilities relative to the module that the EDC had 
for the experiment. In addition, the module development center managed 
the installation and integration testing of the experiment hardware prior 
to module delivery. The actual hardware was developed by contractors 
under the direction of the center project offices. JSC was the Command 
and Service Module development center and MSFC was the development center 
for the other Skylab modules . 

C. Integration Center 

This center was responsible for overall Skylab Bystems engineer- 
ing and integration, which included managing experiment interfaces with 
the total program. The Integration Center maintained a continuing com- 
patibility assessment to assure that all experiments under its cognizance 
were designed, fabricated, tested and operated in complete compatibility 
with all program and experiment requirements; it also participated in the 
resolution of interface problems that arose. MSFC was the Integration 
Center for Skylab and utilized the supporting services of a Systems Engi- 
neering and Integration Contractor. 

In general, experiment integration responsibility was assigned to 
the center developing the module that would carry the experiment. Thus 
MSFC was also the Experiment Integration Center (EIC) for all Skylab 
flight experiments except those in the JSC-developed Command and Service 
Module, or crew procedural experiments involving no special hardware. 
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D. Launch Operations Center 

This center received the integrated modules and launch vehicle 
stages and performed final assembly, test and closeout to ensure that 
the integrated system was ready for launch. The minimum requirements 
for the final integrated systems test were provided by the Integration 
Center to the Launch Operations Center. Launch was controlled from this 
center through countdown and liftoff. Following liftoff, control of the 
mission shifted to the Mission Operations Center, The John F. Kennedy 
Space Center (KSC) was the Launch Operations Center for Sky lab. 

E. Mission Operations Center 

This center was responsible for controlling the mission to 
ensure that mission objectives were satisfied. Prior to launch, this 
center provided crew training and prepared flight planning and mission 
operations documentation. After launch it controlled the mission by 
monitoring all systems and updating preplanned crew activities as 
required. This center was also responsible for recovery operations 
and data dissemination (see Sections VII and VIII). The Skylab Mission 
Operations Center was JSC. 


F. Cost and Schedule Control 

Cost and schedule considerations were an important factor in 
selecting the experiments and continuing them in the program. Intense 
management scrutiny was brought to bear on those experiments that had 
repeated overruns of estimated costs or delays in meeting established 
milestones, which in turn added cost. 

The NASA Office of Manned Space Flight (OMSF), through the 
Skylab Program Office at Headquarters, exercised overall control of 
Skylab budgets, costs and milestone event schedules. A Program 
Operating Plan (POP), compiled and maintained at Headquarters, 
reflected experiment resources commitments as originally approved in 
the Experiment Implementation Plan and subsequently revised by approval 
of inputs submitted by the cognizant centers. The POP was the authori- 
tative summary of program funding and schedules. 

RECOMMENDATION: Prior to approval of an experiment for 

development, insist upon sufficient definition to pro- 
vide realistic estimates of cost ceilings. For this 
purpose, final approval might be withheld until after 
Preliminary Design Review; or funding could be reviewed 
and approved in incremental stages. 
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SECTION III. EXPERIMENT DEFINITION 


Experiments proposed for the Sky lab Program varied from new in- 
vestigations to reflight of experiments from other programs. Some, 
developed during previous programs, had flight hardware already avail- 
able, while others were only concepts and their hardware designs had not 
yet begun. The selection process, (see figure 3) was designed to en- 
sure that experiments approved for Skylab had been thoroughly evaluated 
on the basis of scientific merit and compatibility with the program’s 
objectives, capabilities, schedules and funding. The current (post- 
Skylab) NASA selection process is described in detail in Reference 5, 
and reflects the Skylab experience. 

A. Conceptual Approaches 

Skylab experiment concepts were generated and Implemented by 
either of two approaches. Where an individual scientist conceived an 
acceptable investigation of a specific scientific objective, a single 
experiment was generally developed to satisfy that objective, and the 
originating scientist was identified as the Principal Investigator (PI). 
Most of the experiments were generated in this way. The other approach 
(which gained increasing favor during the Skylab Program) was that of 
implementing an "Orbital Experiment Facility", comprising a group of 
associated instruments dedicated to general investigations of a parti- 
cular scientific discipline, such as earth resources or materials pro- 
cessing in space. Facility instruments were generally conceived by a 
small group or committee of scientists versed in the needs of the dis- 
cipline involved. When the facility concept or preliminary design had 
progressed to the point where its capabilities were reasonably well 
defined, an Announcement of Flight Opportunity (AFO) was issued to 
potential "users" throughout the world. Interested scientists responded 
with proposals for using the facility to gather data for their specific 
investigations. Accepted proposals were contractually implemented with 
the users by the EDC. A NASA Project Scientist at the EDC performed the 
PI functions (and represented the users) for each facility instrument. 
The chief advantages of the facility approach are: much broader usage 

of the instruments and data, and the fact that all the user scientists 
need not be directly involved during the full program duration. 

B. Sponsoring Program Office 

Each experiment required a Sponsoring Program Office to manage 
the conceptual identification and feasibility phase of the experiment 
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definition. For Skylab, the NASA sponsoring offices were the Office of 
Manned Space Flight (OMSF), the Office of Space Science Applications 
(OSSA), and the Office of Advanced Research and Technology (OART) . The 
Department of Defense (DOD) also served as sponsoring office for certain 
experiments. The experiment's scientific discipline generally determined 
the cognizant SPO. 

Having received and concurred with the scientist's conceptual 
proposal, the SPO formally presented it to the MSFEB for preliminary 
consideration, and later for final approval. The SPO subsequently 
monitored the scientific and technical integrity of approved experi- 
ments through all program phases to ensure that experiment objectives 
were satisfied, and that adequate funding was provided. 

C. Approval Cycle 

Once an experiment was recommended by the MSFEB for considera- 
tion, an Experiment Implementation Plan (EIP) was prepared and a com- 
patibility assessment made. 

1. Experiment Implementation Plan . The PI and the designated 
EDC jointly compiled experiment information in an EIP in as much detail 
as possible. In addition to the experiment objectives, the EIP generally 
included preliminary information for the design, fabrication, test and 
delivery of experiment equipment, and the operating procedures necessary 
to perform the experiment. An experiment development schedule and 
estimated funding (resources) requirements were also included. Experi- 
ment development and delivery schedules as required in the EIP were 
necessarily keyed to overall program-controlled milestones and module 
level development and test schedules. Requirements Identified in the 
EIP were concurrently utilized by the Integration Center in performing 
the compatibility assessment. 

2. Compatibility Assessment . This study compared the experi- 
ment's interface requirements with the program's existing capabilities 
and constraints. Where incompatibilities were found, solutions or 
alternate designs were proposed that would satisfy the experiment 
objectives without unacceptable impact to the program. At this early 
stage, the compatibility assessment was necessarily less detailed than 
that described in Appendix B, but approached it as nearly as the pre- 
liminary information would permit. Normally, the Integration Center 
conducted this analysis, with support from the PI, the EDC, and the 
operating centers as required. 

3. Final Review and Approval . The experiment proposal, 
supplemented by the KIP and compatibility assessment, was then resub- 
mitted to the MSFEB for its review and recommendation. The NASA 
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Associate Administrator for Manned Space Flight (who also chaired the 
MSFEB) made the final decision on approval of the experiment for im- 
plementation. 

RECOMMENDATION: Emphasize thoroughness in preparation of 

the EIP dnd conduct of the compatibility assessment during 
the initial experiment approval cycle, for early identifi- 
cation of all program impacts and any major problem areas. 

D. Generation of Requirements 

Upon final approval, two types of experiment requirements were 
generated: the design requirements for the scientific instrument 

development and the integration requirements to support the experiment 
during all phases of the program. The former were stated in a document 
called the End Item Specification (EIS) and the latter were identified 
in an Experiment Requirements Document (ERD) , Both of these documents 
were the responsibility of the EDC; however y the ERD required El an 
operations center support and in some cases was actually prepare y 
the EIC. ["NOTE : Occasionally, in the early stages, the descriptive 

portions of the ERD were used as a substitute for the preliminary EIS, 
but this procedure was generally concluded to be less than satisfactory.] 

RECOMMENDATION: Initiate preparation of the EIS and ERD as 

soon as possible after experiment approval. Since the ERD 
is an integration document, primarily concerned with pro- 
gram-wide interfaces, it should be prepared and maintained 
by the EIC, with support and concurrence from the EDO. 
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SECTION IV. EXPERIMENT DEVELOPMENT 


Upon program approval of the experiment, the hardware development 
proceeded. A series of reviews was held and development and qualifica- 
tion tests performed (see figure 4), to ensure the satisfaction of design 
and interface requirements. The same sequence of reviews and tests was 
imposed on all experiments regardless of the hardware development status 
when approved for Skylab. In general, new tests were waived only when 
it could be demonstrated that previous tests had met or exceeded the 
Skylab requirements. 

Detailed requirements and procedures for the various development 
reviews are described in Appendix C. Appendix D presents a listing of 
specific considerations and constraints pertinent to experiment design. 

An overview of the total experiment testing program is provided in 
Appendix E. 


A. Requirements Baseline 

A formal Preliminary Requirements Review (PR R) was conducted by 
the EDC at the earliest practical date after experiment approval and ED 
selection. The purpose of the PRR was to verify all requirements that 
had to be met to satisfy the experiment objectives, as stated in the 
preliminary EIS and ERD. The PRR was intended to establish as a require- 
ment baseline; a preliminary EIS which properly specified experiment 
requirements in terms of performance criteria and limits; an ERD which 
properly specified experiment interface requirements on the module, crew, 
launch, flight and recovery operations; the number of required end 
items (i.e., flight, backup, test and training units, mock-ups) and their 
schedules; and the development program plan. 

RECOMMENDATION: Involve operations personnel to help 

identify, assess and resolve the impacts of operational 
requirements upon experiment design (and vice versa) 
al the earliest possible stage of development, to permit 
tradeoffs for the efficient use of crew time and space- 
craft capabilities during the mission. Consider the 
feasibility of unattended or ground-controlled operation 
for repetitive or time-consuming functions that do not 
require onboard crew judgment. Minimize experiment 
impacts on concurrent spacecraft activities. 

B. Experiment Design 


Implementation of the EIS requirements into hardware design 
was accomplished in two phases: the design approach, approved at 
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the Preliminary Design Review (PDR) ; and the detail design, approved 
at the Critical Design Review (CDR) . 

Development activities leading up to the PDR were to: 1) accom- 

plish hardware preliminary design (subsystem block diagrams, overall 
dimensions, etc.), based upon the technical requirements of the base- 
lined EIS; 2) perform trade studies to evaluate alternate concepts for 
subsystems, consistent with the experiment PRR; 3) perform the develop- 
ment activities that verify new subsystems, manufacturing processes, 
logic design, etc.; 4) define EIS requirements for the GSE; and 5) prepare 
reliability, quality control, maintainability and safety requirements 
sect ions for the experiment EIS. 

RECOMMENDATION: Conduct necessary trade studies between 

scientifically desirable and technically achievable 
requirements (e.g., pointing tolerances) as early as 
possible in the development process, to avoid downstream 
incompatibilities . 

The PDR was then conducted by the EDO, wherein a design approach 
was selected to proceed to final design of flight hardware. The experi- 
ment PDR objectives were to: 1) approve the selected design approach 

for the flight hardware; 2) evaluate the justification for the design 
approach shown (by trade studies, technical reports, and/or development 
tests); 3) approve the technical requirements for mock-ups and GSE as 
stated in EISs for these articles; 4) review the adequacy of preliminary 
Interface Control Documents (ICDs) provided by the Module Development 
Center (see Section V); 5) approve the verification plan for the 
selected design; 6) approve producibility of the hardware; and 7) approve 
the completed flight hardware EIS with plans for quality, reliability, 
safety, and maintainability. 

Following PDR, the experiment design proceeded to completion. 

Final detailed schematics and drawings of all parts were based upon the 
EIS, ICDs, and the approved design approach from the PDR. Appendix B 
lists a number of specific considerations that were recognized in the 
detail design of Skylab flight hardware and GSE. 

RECOMMENDATIONS: In addition to the detailed design con- 
siderations recommended in Appendix D, the following 
general design philosophy criteria are particularly 
emphasized: 

o Carefully evaluate the cost-effectiveness of using 
existing hardware for new programs. 
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o Build in safety features (e.g., interlocks, limit 
switches, etc.) to protect the hardware and/or 
enhance serviceability. 

o Standardize crew interface hardware, 

o Emphasize simplicity of operation as a primary design 
objective (e.g., avoid multiple switching operations 
that would permit selection of invalid modes or require 
time delays to preclude logic race conditions). 

o Design manned spaceflight hardware to facilitate 
in-flight maintenance (e.g., provide accessibility 
and suitable workstations with restraint aids fot 
crewmen, documents, small parts and tools). 

o Provide telemetry or crew status indicators that give 
direct readout of specific parameters needed for in- 
flight assessment of experiment operation or for 
troubleshooting hardware malfunctions . 

o Ensure existence of capability for in-flight visual 
observation of external experiments. 

During this phase, the qualification and acceptance test 
specifications were prepared, based upon limits in the EIS and pre- 
liminary ICDs. A development (prototype) unit was usually fabricated 
and used for development tests of new design, data system, unusual 
manufacturing processes, etc., and for crew training. 

The design was then reviewed for compatibility with require- 
ments at the experiment CDR. The CDR results were: baselining of 

the approved detail design of the flight hardware, qualification unit, 
and GSE for release to manufacturing; approval of qualification and 
acceptance test specifications; approval of test and manufacturing 
facilities; and a review of development test results to certify that 
design and manufacturing would involve minimum risk. 

RECOMMENDATION: Baselined experiment design should not be 

dependent on unproven advanced state-of-the-art features. 
Resist product improvement type changes after baselining, 
unless they clearly enhance the probability of mission 
success and/or improve cost-effectiveness. 
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C. Fabrication and Test 


Using drawings approved at CDR, fabrication activities began. 

The number of hardware units fabricated was a variable, generally 
depending upon the experiment's complexity, schedule and budget. 

In addition to the previously mentioned development prototype and the 
flight unit, there was normally a flight backup unit, a qualification 
test unit and various training units, simulators and mock-ups. (In 
some cases, to minimize cost, it was found acceptable to reuse the 
same hardware for more than one of these applications.) The qualifica- 
tion unit, flight unit, and backup unit or spare parts were all built 
and assembled to the same design drawings. 

RECOMMENDATION: Carefully evaluate the need for multiple 

hardware, trading off the apparent cost against the risk 
of needing additional hardware too late in the program 
to produce it without excessive cost or delay. 

At the earliest possible date, the qualification unit was fabri- 
cated and subjected to qualification tests, to verify that the design 
was compatible with specified environments. Whenever the qualification 
unit failed a test, corrective action was taken. If this involved a 
new design or a modification to the qualification unit, it was necessary 
that the new design or modification be incorporated into the flight and 
backup units. 

The flight unit was subjected to an acceptance test, usually at 
levels less severe than the qualification test but adequate to verify 
conformance to the design requirements of the EIS. 

During this phase also, the EDC and ED participated in meetings 
with the Integration, Module Development, and Launch Operations Centers 
to establish the test requirements for postacceptance integration test- 
ing (see Section V.C). 

RECOMMENDATIONS: Supplementing the details in Appendix E, 

the following recommendations apply to experiment testing 
In general: 

u Provide experiment hardware and perform testing in 
the logical order (i.e., have the development 
unit available early in the program, and complete 
development and qualification testing prior to 
flight hardware acceptance). 
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o Emphasize early identification and timely baselining 
of test and GSE requirements and responsibilities - 
preferably as early as PDR. Minimize configuration 
variations in GSE sets to be used for identical tests 
at different test sites. 

o Utilize a team of test/ experiment integration specialists 
to develop appropriate integration test plans and 
requirements . 

o Place more reliance on experiment development, quali- 
fication and acceptance test results to reduce 
integrated testing. 

n Consider the cost-effectiveness of using interface 
simulators to minimize interface verification tests 
at the module level, and to preclude premature 
experiment hardware delivery. 

o Support all experiment testing, both preacceptance 
and postacceptance, with cognizant experiment 
development and integration personnel for timely 
problem identification and corrective action. 

D. Acceptance and Delivery 

Following fabrication and test, a Configuration Inspection Re- 
view (CIR) was held to verify that the flight hardware to be accepted by 
the EDC conformed to the approved design configuration. Qualification 
and acceptance test results were assessed for validity and conformance 
to requirements. The CIR also verified that the Acceptance Data Package 
(ADP) was complete and that problems which occurred after CDR had 
been properly resolved. The ADP provided a complete set of descrip- 
tive data for each deliverable end item, which was maintained current and 
physically accompanied the hardware when shipped from site to site. 
Appendix A includes a full description of the ADP contents, A DD250 
(a NASA form for formal acceptance of the hardware), indicating any 
shortages or open work items to be resolved prior to Flight Readiness 
Review, was approved by the EDC at the completion of the CIR. Prior to 
shipment from the point of manufacture, a Certificate of Flight Worthi- 
ness (CO EW) was prepared and endorsed by the EDC representative (see 
Appendix C) . 

RECOMMENDATION: Define a standard list of minimum 

necessary ADP requirements, acceptable to all centers 
involved, and implement it contractually on all hardware 
developers . 
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E. Late Experiment Additions 


The value of the Skylab missions was considerably enhanced by 
approval, late in the program, of many new experiments (e.g., the 
Multipurpose Electric Furnace, the Student Experiments, and the Comet 
Kohoutek Observing Program). To develop these experiments without 
Impacting launch dates required an expedited approach to the methodology 
just described. One aspect of this approach was the use of a specialist 
team to prepare major experiment development documentation. Integration 
personnel, already familiar with the interfacing module systems and with 
Skylab documentation requirements, were assigned to assist the EDs in 
preparing such documents as the EIS; Failure Mode and Effects Analysis 
(FMEA); Hazards Analyses; Operation, Maintenance and Handling (OM&H) 
procedures; Materials List; etc. The results were timely, complete, 
consistent and correctly formatted documents, prepared at minimal cost. 

RECOMMENDATION; Expand upon the Skylab usage of specialist 
teams for preparation of major experiment development docu- 
mentation, to preclude each developer having to go through 
his own learning cycle. Consider using similar teams for 
experiment-related integration documentation as well. 
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SECTION V. EXPERIMENT INTEGRATION WITH THE MODULE 


Development of the modules that carried the experiments proceeded 
in parallel with the experiment development, as indicated in figure 1. 

The modules followed a similar pattern of design reviews, fabrication and 
testing. In addition, however, experiment Installation and Integration 
testing were performed prior to final module acceptance and delivery to 
the launch site (see figure 5). 

A, Module Requirements Baseline 

A PRR was conducted by the Module Development Center to baseline 
the technical requirements for the module. The mission and total orbital 
assembly (cluster) requirements were reviewed (e.g., mission orbital 
parameters and durations, module descriptions and interface requirements, 
experiment assignments to modules, control weight allocations, power 
profiles, pointing requirements, natural and induced design environments, 
etc.). |NOTE: As the program progressed, the need was recognized for 

a separate specification identifying these overall system requirements 
Imposed at the cluster level. An intercenter Cluster Requirements Speci- 
fication (CRS) was accordingly implemented, and became, in effect, the 
top-level End Item Specification^ Experiment requirements identified 
in the ERDs, current compatibility assessments and integration plana and 
schedules were also reviewed at PRR. These activities, together with 
completion of any PRR action items, established the program requirements 
baseline for the module. 

RECOMMENDATION: Early in any new program (preferably prior 

to module and experiment PRRs) establish and baseline the 
equivalent of the Skylab Cluster Requirements Specification 
and Impose it upon all program elements, to ensure program- 
wide compatibility with overall requirements (e.g., opera- 
tional environments). At module PRR, formalize the module 
requirements baseline in a preliminary module EIS. 

B. Module Design and Integration 

The module design and integration proceeded in parallel with 
the experiment development activities (see Section IV). Module develop- 
ment activities included: 1) the basic analysis and design to meet 

module requirements; 2) developing preliminary experiment iCDs for use 
in the experiments' final design, including definition of the module 
technical inputs (e.g., dynamic and static loads, number and type of 
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electrical connectors, power level, voltages, etc.); 3) a continuing 
compatibility assessment to show status of design conformance to re- 
quirements and to provide management visibility of problems; 4) pro- 
viding overall module system block diagrams; 5) defining GSE require- 
ments; and 6) establishing subsystem add-ons (batteries, propellant, 
etc.) to satisfy mission requirements. 

A module PDR was held to baseline the preliminary module design 
and the integration approach-. The preliminary EIS and block diagrams, 
drawings, matrices, etc., of each subsystem were reviewed to show con- 
formance to technical requirements of the CRS. The technical adequacy 
of the module design, ICDs, module FMEA, GSE requirements, an updated 
integration plan, schedules and compatibility assessments were also 
reviewed . 

Final module detail design and integration was then started, 
utilizing the PDR baseline. This involved: 1) preparing engineering 

drawings of all parts and assemblies, detail schematics, wiring dia- 
grams, etc.; 2) building of a high-fidelity mock-up of the integrated 
system for review at the CDR; 3) the detail design of all module-provided 
GSE; 4) preparation of manufacturing and assembly plans and drawings; 

5) preparation of qualification and acceptance test specifications; 

6) completion of the module development program (cable layouts, struc- 
tural vibration, etc.) to support final design; and 7) fabrication of 
mechanical interface GSE (provided to some experiment developers prior 
to delivery of flight experiments for verification of interfaces dur- 
ing their acceptance testing). 

The module CDR occurred after the majority of the experiment CDRs . 
Review items included: 1) analyses that supported the design; 2) de- 

tail drawings and plans; 3) the module FMEA; 4) module qualification 
and acceptance test specifications; 5) mock-ups; and 6) ICDs. The 
CDR baselined the final design configuration of the module. 

C. Integration Test Requirements and Procedures 

During the final phase of experiment development, the Module 
Development Center/contractor made preparations for receipt of the 
experiments and for the assembly and testing of the module subassemblies. 

In testing the module, experiment electrical simulators (built by ex- 
periment developers) were sometimes used in place of actual hardware. 

This provided confidence in the design and eliminated many problems 
prior to flight unit delivery. Special Post-Acceptance Test Require- 
ments and Specifications (PATRS) meetings were held with each EDC/ED 
and the Integration and Launch Operations Centers, to develop experiment 
requirements and criteria inputs for the module /experiment integration 
tests and related portions of the integrated systems tests at the launch 
site. The output of these meetings was a coordinated Experiment Integra- 
tion Test Requirements and Specifications (EITRS) document, prepared by the 
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Integration Center and concurred with by all other centers and contractors 
involved. The Module Development Center then compiled these requirements 
and limits into a Test and Checkout Requirements and Specifications Docu- 
ment (TCRSD) for the module, from which the detailed experiment integra- 
tion test procedures* were subsequently prepared by the center responsible 
for conducting the tests. 

RECOMMENDATION: Baseline EITRS documents for the various 

experiments and module TCRSDs (or equivalents) as early 
as possible, and maintain at least the TCRSDs under Level 
II change control, to ensure clear and complete definition 
of integration test requirements for all program elements. 

Maintain uniformity of procedures for performing identical 
tests at different test sites. 

D. Physical Integration, Acceptance and Delivery 

The module now entered the final acceptance phase prior to 
delivery to the launch site. Upon receipt of each experiment at the 
module site, It was subjected to an unpowered receiving and inspection 
test for transportation damage and completeness of parts and documenta- 
tion. The hardware was then installed in the module, using module 
assembly drawings and the experiment OM&II. A powered functional inter- 
face verification (FIV) test of the experiment with the module was per- 
formed to verify that all electrical and mechanical interfaces conformed 
to the specifications in the TCRSD. Following FIV tests for all exper- 
iments, a simulated mission test was conducted for the integrated system. 
Some flight crewmen generally participated In this system test as part 
of their crew training. 

RECOMMENDATION: Encourage participation in experiment/ 

module integration tests by all flight crewmen who may be 
required to operate the experiment during the mission (s). 

Upon successful completion of all testing, a module CIR was held. 
The integrated system test results were reviewed to verify that the 
module had met the established requirements. A module DD250 and COFW 
were executed by NASA, and the Integrated module was then shipped to the 
launch site. Any experiment or subsystem that was removed for separate 
shipment needed interface reverification at the launch site when it was 
reinstalled. Experiments that were returned to the developer for modi- 
fication or final calibration prior to shipment to the launch site 
required an additional endorsement on their DD250 and COFW by the EDC. 


* If flight checklists (see Section VII) were available from the Mission 
Operations Center, these test procedures followed the checklists as 
closely as possible. 


22 



RECOMMENDATION: Discourage removal of experiments after 

module integration and acceptance. When this is unavoid- 
able, emphasize critical configuration control and main- 
tenance of appropriate records by all parties involved. 

E. Continuing Compatibility Assessment 

The evolution of the experiment concepts and module designs to 
hardware was supported throughout by a continuing compatibility assess- 
ment, conducted by the Integration Center. This assessment monitored 
the experiment interfaces with the program for compatibility, proposed 
and coordinated solutions to experiment incompatibility problems, and 
provided management visibility of the experiment integration status. 
Further details of this activity are provided in Appendix 8. 

RECOMMENDATION: Follow the Skylab practice of utilizing a 

highly qualified, specialized experiment integration team. 

Assign responsibility for each experiment (or group of 
related experiments, depending upon complexity) to an indi- 
vidual engineer, to act as the single-point source for com- 
piling and disseminating experiment requirements and other 
integration information. Assign responsibility for com- 
patibility of experiments with each carrier system or 
program discipline to .an individual systems engineer, to 
facilitate experiment liaison with other project groups. 

Conduct continuous compatibility assessment and frequent 
reviews throughout the development and integration phases, 
providing timely management visibility of problem status. 
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SECTION VI. PRELAUNCH INTEGRATION AND LAUNCH OPERATIONS 


Prelaunch and launch activities (see figure 6) were conducted 
by the Launch Operations Center, with the cognizance of the Integration 
Center and the support of the Development and Mission Operations Centers. 
The peak activity at the launch center obviously occurred after the 
launch vehicles, modules and experiments were delivered, but there was 
significant activity prior to this time to establish the test and 
facility requirements and test procedures. Tasks performed to identify 
these requirements, as related to experiments, began when the experi- 
ment was approved for the program and continued throughout the develop- 
ment and integration phases. 

A, Launch Center Test Preparations 

Prior to receiving the module hardware, postacceptance test 
requirements, specifications and constraints for each experiment were 
reviewed and approved in a series of formal PATRS meetings, attended 
by representatives from all centers (see Section V.C), Following 
these meetings, the Module Development Center compiled the applicable 
module/ experiment test requirements, specifications, and criteria 
necessary for prelaunch checkout and launch operations into the module 
Test and Checkout Requirements and Specifications Document. 

Similarly, the Integration Center prepared a TCRSD for the combined 
integrated systems test. Using the agreed-upon TCRSD, the launch center 
prepared detailed test plans and procedures for satisfying these 
requirements, subject to review by the Integration and Development Centers. 
The launch center also benefited from participation in the Systems/ 
Operations Compatibility Assessment Review (see Section VII. A. 2). 

B. Receiving and Inspection 

Upon arrival at the launch center, all hardware (Including 
GSE) underwent Receiving and Inspection (R&I) . The hardware was 
examined visually for any damage Incurred during shipment. The ADP 
was examined for completeness of all documentation and certifications 
required for acceptance by the launch center. Any available transporta- 
tion environmental information, such as temperature profiles, passive 
accelerometer data, etc., was reviewed to assure that handling and 
shipment constraints had not been violated. 

Experiments that were transported to the launch center 
integrated within the module passed through Receiving and Inspection 
with the module. Experiments shipped separately from the module were 
received independently with their own Acceptance Data Packages. 
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Experiments not installed on-module, or actively involved in tests, 
were placed in an environmentally controlled bonded storage area until 
required for use. All GSE underwent a checkout to ensure that 
it functioned properly before being mated to flight hardware. 

C. Prelaunch Integration Tests 

Following R&I , testing at the launch center emphasized system- 
to-system interface verification. Individual experiment testing was 
minimized and consisted mainly of necessary reverification of interfaces 
and final calibrations. 

The activities at the launch center included: 1) the assembly 

and integration of modules to the launch vehicle; 2) verification of 
all instrumentation, communication, environmental, electrical, mechani- 
cal, and structural interfaces; 3) integrated systems tests which 
exercised individual systems as well as combined systems to verify 
overall space vehicle functional compatibility; 4) final Crew Compartment 
Fit and Function (C F^) checks to assure flight crew members of proper 
hardware integration, accessibility, and safety considerations; 5) final 
calibration of experiment sensors; 6) stowage of perishable ftltsfema; iand . 
7) securing of all hardware prior to 'launch. i . 

D. Design Certification Review 

As part of a final assessment and certification of the design 
of the total mission complex, the Design Certification Reviews (DCR) for 
experiments and modules were held. All involved centers participated 
and the review was conducted by the NASA Headquarters Program Office. 

DCR activities began prior to flight hardware shipment to the launch 
center and ended during launch center operations. The purpose of the 
DCR was to examine the experiment/module hardware design and the 
design verification programs in order to certify that the overall 
design had met the program objectives for flight worthiness and flight 
safety. 


The following topics were covered at the DCR: 1) an analysis 

of the purpose, design, and interface compatibility of the experiments; 
2) a summary of actions taken as a result of previous experiment 
reviews; 3) a review of safety and reliability considerations included 
the hardware design; 4) a review of mission rules and contingency 
plans; 5) an analysis of all prior hardware test programs; and 6) the 
status of any remaining open action items. 


26 



E. Flight Readiness Review 


The Flight Readiness Review (FRR) was held at the launch center 
prior to launch. This review assured program management that all aspects 
of the space vehicle, launch vehicle, launch complex. Mission Control 
Center (MCC) , ground instrumentation and networks were ready for flight 
operations. 

The following topics were reviewed at the FRR: 1) the status 

of action items resulting from the DCR; 2) any hardware configuration 
changes that had occurred since the DCR; 3) the current status of pre- 
launch integration testing at the launch center; 4) the. status of major 
anomaly reports; 5) a summary of all significant problems that arose 
during testing, and their solutions; and 6) a summary of waivers or 
deviations that had been granted since the DCR. 

F. Launch Operations 

At the conclusion of the FRR, all testing and stowage was com- 
pleted and attention focused upon final closeout of the entire flight 
vehicle. The launch center was responsible for the launch countdown, 
with the support of the Mission Operations Center. When the flight 
vehicle cleared the launch complex (i.e., umbilical tower), full respon- 
sibility for flight direction reverted to the Mission Operations Center 
(except that the Air Force Range Safety Officer at the launch site 
retained the option of intervening if range safety became endangered). 
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SECTION VII. MISSION AND RECOVERY OPERATIONS 


Once the launch vehicle was in flight, the entire mission was 
under the direct control of the Mission Operations Center. The pro- i 
cedures and techniques used to perform these functions had been under 
development and rehearsal since the early phases of the program. 

Figure 7 depicts the premission preparations and real-time functions 
involved in conducting the mission and recovery operations. 

A. Premission Preparations 

Concurrently with hardware development and integration, 
preparations were made for the operational phase of the mission. 

This activity included the generation of mission and mission support 
documents, reviews of applicable program documentation, crew training, 
and the establishment and verification of operational readinesB through 
mission simulations. 

1. Documentation Preparation . Using the ERD and module require- 
ments, the Missions Operations Center prepared the basic mission docu- 
ments.* The primary requirements documents were the Mission Requirements 
Document (MRD) and the Reference Flight Plan (RFP) . The MRD defined 
the requirements and constraints for both the mission and the individual 
experiments. The RFP converted the MRD information into a detailed 
timeline of crew activities during the mission. These documents were 
utilized during the design and integration phases to show that adequate 
time and systems support would be available to perform the mission. 
Shortly before launch, the updated RFP became the actual Flight Plan. 

The RFP did not contain the detailed steps for performing a function, 
but was limited to referencing the function (e.g,, load film). The 
Mission Operations Center prepared Checklists for each function (e.g., 
the detailed steps for loading the film), based upon Volume II of the 
OM&H. The Checklists and Flight Plan were launched with the crew 
even though they would be updated during the mission. Other operational 
documents (e;g., Flight Mission Rules, Operational >Data. 'Books , etc.) were 
prepared to provide further details; these are described in ■ Append ixeAe i 

RECOMMENDATION: Since Skylab premission estimates of crew 

time required to perform work tasks in the orbital environ- 
ment were not always proven accurate in real time, utilize 
Skylab mission experience correlations (notably Experiment 
M151, Time and Motion Study) for quantitative crew task plan- 
ning for future missions. 


* Although Data Request Forms (DRFs) were also prepared to identify data 
processing requirements during the mission, the discussion of the DRF 
is in Section VIII, Data Processing, Analysis and Reporting. 
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2. Operations Compatibility Reviews . To assure an integrated 
approach to mission operations, a series of Experiment Operations Plan- 
ning (EOP) meetings was convened during the development and integration 
phases. These meetings brought together representatives of experiment 
development and integration, mission operations, flight planning, PI/ 
users, and various mission support groups for the purpose of assuring 
that compatibility existed between experiment objectives and experiment 
operations. Documentation pertaining to experiment operational require- 
ments and techniques was reviewed and compared for consistency with ex- 
periment objectives. Potential operational conflicts between experiments 
were resolved. 

A more formal program-wide review, the Systems /Operations 
Compatibility Assessment Review (SOCAR) was conducted prior to DCR. 

It consisted of a series of preliminary meetings, similar to EOPs, but 
involving design/development and integration personnel for all Skylab 
systems, interfacing with the operational personnel at both launch and 
mission operations sites. It culminated in a formal presentation, by 
system, to senior program management. The SOCAR was generally con- 
sidered quite effective in enhancing the program's operational readi- 
ness. 


RECOMMENDATION: Incorporate the equivalent of the Skylab 

SOCAR in the formal program milestone reviews, to be con- 
ducted at the appropriate time to assure maximum coordina- 
tion and subsequent readiness of the operational planning. 

Crew Training . Maximum efficiency during on-orbit opera- 
tions is attained when the flight crew is thoroughly familiar with the 
hurdware and the general objectives. To this end, the Skylab flight 
crews underwent extensive training, first with high-fidelity mock-ups 
of the experiments and modules provided by the hardware developers. 
Later, during integration tests at the module development centers 
(Section V) and at the launch center (Section VI), crewmen were used 
fn place of technicians for operating the flight hardware at every 
opportunity. To simulate mission activities, the procedures for those 
tests involving crew participation utilized the actual flight check- 
lists wherever possible. 

RECOMMENDATION: Follow up any problems or deficiencies 

encountered during crew training, to assure proper reso- 
lution and incorporation of any resulting hardware and/or 
operational changes. 

Missio n Simulations . Prior to launch, a serieB of mission 
simulations was performed, to exercise the flight and support personnel 
in a realistic mission environment. For the purpose of these simula- 
tions, the mission was divided into distinct phases, e.g., launch, 
first-day activities, activation, orbital operations, etc. Each 
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simulation was directed at a particular mission phase and covered a 
period ranging from one 24-hour mission day, early in the simulation 
program, to three consecutive 24-hour days as proficiency improved. 

All activities directly involved in mission support were exer- 
cised, in an atmosphere designed to reproduce the actual mission environ- 
ment insofar as possible, even to the extent of introducing hypothetical 
malfunctions and anomalies. Basic coordination, information flow and 
operational procedures were established during these simulations. Fol- 
lowing each simulation, a debriefing was conducted to discuss any opera- 
tional problems uncovered, and corrective procedures were developed to 
preclude their recurrence during the actual mission. 

RECOMMENDATION: Conduct comprehensive prelaunch mission 

simulations, utilizing all applicable communications, data 
links and support personnel. 

B, Mission Control 

Following launch, all phases of the mission were under the con- 
trol of the MCC, located at the Mission Operations Center. This in- 
cluded planning for and operation of all module systems and maneuvers, 
crew activities and experiment operations, from launch through recovery. 
Activities were planned in near-real time on a daily basis, and all 
aspects of mission operations were continuously monitored from the 
ground. 


The Flight Operations Director was responsible for the mission 
operations and provided the management interface between the Flight 
Director and Program Management. The Flight Director, operating from 
the MCC, had the direct responsibility for mission control. 

The general mission control functions accomplished by flight 
controllers, with the technical support of other centers and support 
teams, were to monitor and evaluate, in real and near -real time, the 
module systems, instrument systems, scientific data, flight plan activi- 
ty, condition of the flight crew, and trajectory data. Based upon these 
data, decisions were made concerning the progress of the mission toward 
satisfying mission objectives and the Detailed Test Objectives from the 
MRD, and the need for proceeding to alternate flight plans. The flight 
crew was then advised of updated mission instructions and flight plans, 
systems anomalies found during ground monitoring, ground evaluations 
and recommendations to solve or circumvent any anomalies. 
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C. Crew Operations /Flight Planning 

The level of experiment accomplishment is related to the efficiency 
of the crew operations. A prime consideration during flight plan genera- 
tion is the effective utilization of crew time. In any twenty-four-hour 
period, a fixed percentage of time must be devoted to crew personal 
activities such as sleep, meals, exercise, personal hygiene and rest 
periods. The remaining time (approximately ten hours each day was avail- 
able on Sky lab) is devoted to experiment operation and, as required, 
systems housekeeping. 

Each day during the mission, a flight plan was generated by the 
MCC to cover the following day's activities. This plan, identical in 
format to the premission Flight Flan, was distributed to all mission 
support groups for review and comment and, after incorporation of approved 
recommendations, the final version was uplinked to the crew via tele- 
printer before initiation of that day's activities. Specialized informa- 
tion peculiar to that day's flight plan, such as critical times for target 
acquisition, precise exposure times or alterations to the on-board pro- 
cedures checklists, were also uplinked as "preadvisory data" messages 
(referred to as PADs). The PADs functioned as addenda to the informa- 
tion stowed on-board in the Flight Data File (flight plan and checklists). 

D. Mission Operational Support Teams 

The functioning of the MCC during the missions was backed up by 
an extensive support organization, both on-site at the Mission Operations 
Center and remote at other NASA centers and contractor facilities. The 
Huntsville Operations Support Center (HOSC) was the focal point of MSFC 
support activities and fulfilled a major role in the conduct of the mission. 
Support teams, organized by science/ technical discipline or by spacecraft 
system, were composed of representatives from the development and integra- 
tion centers, contractors and Pis. They monitored the mission progress 
in real time, and provided the MCC with immediately available expertise 
relative to any experiment or system anomaly that arose. Each team ini- 
tiated and/or reviewed proposed mission changes to ensure satisfaction of 
the requirements and constraints of their particular area of concern. 

Their basic task was to assure the optimum success of their experiments 
in the face of whatever off-nominal conditions might occur during the 
mission. The primary areas of team concern were: 1) continual planning of 

future activity necessary to achieve maximum experiment success with relation 
to all other mission parameters, and 2) rapid and accurate response to any 
in-flight anomaly, either vehicle or experiment-related, to maximize the 
experiment data returned under the prevailing conditions. In connection 
with the flight planning activity, the Sky lab experiment support teams 
made regular Inputs to the "Science Planning Meetings," conducted twice 


32 



weekly by the Program Scientist at the Mission Operations Center, which 
proved to be an effective means for influencing the MGC flight planning. 

RECOMMENDATIONS: The primary recommendations resulting 

from Sky lab experiment mission support experience were: 

o Utilize personnel for mission support who have 
participated in experiment development and/or 
integration and have experience with hardware- 
related problems. Ready availability of the Pis 
or their authorized representatives is highly 
desirable, particularly for the more complex 
experiments. 

o Provide near-continuous communication between space- 
craft and MCC, more direct communication and data 
links between MCC and the mission support teams, 
and fewer intermediaries between the teams and the 
flight crew during anomaly troubleshooting. Also, 
limited but frequent direct communications between 
the flight crew and the Pis are both feasible and 
productive. 

o Provide mission support teams with available experi- 
ment hardware to permit realistic ground simulation, 
facilitating real-time troubleshooting. 

o Utilize trainer walk-throughs by ground-based 
astronauts to check out late additions and real- 
time procedural changes before transmitting them 
to the crew. 

o Emphasize active participation of experiment 

mission support teams in influencing preparation 
of daily flight plans by maintaining liaison with 
the MCC flight planners and supporting semiweekly 
science planning meetings. 

E. Recovery Operations 

Operations at the recovery site were planned to ensure that 
the Integrity of physically returned experiment data (primarily 
photographic film and specimens) was not compromised and that pre- 
scribed handling and delivery requirements were satisfied. These 
requirements, along with any applicable support functions, had been 
identified early in the program. Preliminary recovery site require- 
ments for each experiment were Identified in the original ERDs , and 
specific handling procedures were later defined by means of DKFs. 
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These forms were used to detail temperature and humidity limits to be 
observed, shielding requirements if applicable, special containers 
required to protect the data, or other handling techniques necessary 
to isolate the material from the external environment. 

Following retrieval of the crew and spacecraft, recovery site 
operations included deactivating potentially hazardous systems and 
securing the module subsystems; initiation of ground support functions 
such as purges, thermal conditioning, ground power, etc,; and the 
retrieval of experiment and subsystems flight data. The returned data 
were removed and packaged for transportation to the data distribution 
center and subsequent processing and/or dissemination to the Pis and 
data users. 
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SECTION VIII. DATA PROCESSING, ANALYSIS AND REPORTING 


Data requirements of the experiment Principal Investigator or 
data user were initially stated in ERDs and subsequently amplified in 
DRFs. Using these requirements, the Mission Operations Center developed 
the plans and software required to retrieve, process and distribute all 
flight data. The development centers were responsible for the Mission 
Evaluation Reports, and the Principal Investigator or data user was 
responsible for scientific data analyses and reporting of results. 

Figure 8 shows the functional flow for this phase. 

RECOMMENDATION: Clearly define the respective 

responsibilities of NASA, and the participating 
scientists in the following areas: 
o Funding 

o Data retrieval, processing and delivery 
o Systems performance data required 
o Proprietary rights to data 
o Reporting requirements 

o Data security, accountability and archiving 
o Involvement in Public Affairs Office activities. 

This was accomplished late in the Skylab Program by 
implementation of the Experiment Scientific Data 
Analysis and Reporting Documents (ESDARDs). 

A. Premission Preparations 

During the premission phase, arrangements were made for the 
acquisition of data pertinent to experiment success. The initial 
requirements were stated in the ERDs. The DRF was later employed as 
the formal method of requesting data for all users. The data required 
for the scientific investigations was defined by the Pl/user, docu- 
mented on DRFs, and submitted to a data requirements group at the 
Mission Operations Center for approval, processing and implementation. 
The DRFs specified the data recipient, the pertinent data required, the 
specific times during the mission when the data was to be acquired, 
desired format, and the date when the data was needed. 

Based upon the DRFs, the Mission Operations Center prepared 
software programs for general processing of the flight data. Further 
(more detailed) processing, required by certain experiments, was 
provided by the cognizant EDC . Available programs were exercised 
during the mission simulations, using recorded data generated during 
the integration tests. 
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RECOMMENDATION: Skylab data processing and analysis 

proved to be far more complex and time-consuming 
(and therefore more costly) than anticipated, indi- 
cating the need for more emphasis on premission 
rehearsals of the entire sequence, in order to op- 
timize the operations, shorten data retrieval time, 
and determine realistic time and cost requirements 
for these activities. 

B. Flight Data Processing 

Flight data was received and catalogued at the Mission Opera- 
tions Center both during and after the mission. Returned flight 
samples were released to the PI for examination and analysis. Opera- 
tional film and much of the scientific film were processed by the 
Mission Operations Center and duplicates distributed to the data 
users. In special cases, scientific films were delivered to the Pis 
for processing and analysis, with the understanding that the original 
flight film and a reproducible master were to be returned to archives 
at the completion of the analysis. Recorded and telemetry data were 
processed through appropriate software programs and reduced to com- 
puter-compatible tapes prior to release to the data users. Other 
requested data formats included: tabular forms, strip charts, micro- 

film, transcripts, video tapes and digital television displays. 

C, Data Accountability 

The PI was normally granted proprietary use of the returned 
scientific data for a one-year period after all requested data was 
delivered to him. He was responsible for the physical security and 
integrity of all mission data received by him while it was in his 
possession. He was required to take proper action to prevent loss, 
theft or unauthorized use of this material (refer to MSFC Management 
Instruction 4010.2). At the conclusion of this period, all orbital 
material was required to be returned to the EDC archives. Thereafter, 
NASA retained control of the returned material for possible further 
scientific investigations. 

D. Scientific Data Reporting 

A PI was normally granted Initial publication rights to 
experiment data for a period of one year. Each PI was responsible 
for generating periodic reports of his investigative findings at 
intervals of 30 days, 90 days, 6 months and 1 year after splashdown. 
Normally, within the 1-year period, the PI was to deliver a final 
report of his experiment results for publication. [NOTE: The PI*s 

proprietary and publication rights, indicated above, will in no way 
preclude government access to and use of data for mission analysis, 
troubleshooting, or other official purposes^ 
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E. Mission Evaluation Reports 


The cognizant NASA centers were required to prepare Systems 
Mission Evaluation Reports within six months following mission comple- 
tion, These reports (see References 6 and 7) contained performance 
evaluations of experiment and systems hardware for which the reporting 
NASA center had development responsibility, and also assessed the 
degree to which operational constraints and interface requirements had 
been met during the mission. They did not attempt to evaluate the 
scientific significance of experiment data. 

F. Final Technical Reports 

Concurrently with preparation of the Mission Evaluation Reports, 
the EIC prepared a final technical report (Reference 8), tracing the 
evolution of Skylab corollary experiment development and integration 
from the initial experiment concepts through mission operations. Simi- 
lar final technical reports were produced for the Apollo Telescope 
Mount experiments (Reference 9) and for each Skylab module. 
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SECTION IX. CONFIGURATION MANAGEMENT 


The configuration management system provided a control cycle 
for systematic evaluation, coordination and approval or disapproval of 
all proposed changes to baselined specifications, hardware or systems, 
to ensure that all involved organizations were working to common con- 
figuration baselines. Early identification, timely baselining, and 
accurate, up-to-date maintenance of the hardware configuration status 
and related design and operational documentation are essential to 
effective program management, if for no other reason than to minimize 
changes. The application of refined configuration management methods 
and controls contributed to the successful integration of Sky lab. 

RECOMMENDATIONS: Configuration management can be 

made more straightforward (and thus less costly) if the 

following documentation ground rules are adhered to: 

o Establish a clear-cut, nonredundant documentation 
tree early in the program, and enforce it on all 
program elements. 

o Definitive information should appear in only one 
document, and each document should be tailored 
to suit its purpose, omitting nonpertinent or 
redundant information. 

o Impose program-wide standard formats for major 
document types, such as EIS and ERD. 

o Baseline documents prior to initiation of activi- 
ties that require^ their guidance* . 

o Formally delete documents (or sections thereof) 
from the program as soon as their purpose has 
been served. 

A. Configuration Control Organization 

The primary organizations responsible for the Skylab configura- 
tion control system were; 

1. Configuration Control Boards . The CCB was a primary function 
of the systems engineering activity and included representatives from 
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the various project offices and technical systems disciplines as appro- 
priate. Control of the many interrelated documents (see Appendix A) was 
accomplished on a multilevel basis: 

The Level I CCB approved changes to the baselined overall pro- 
gram requirements, including program objectives, experiment assignments, 
major schedule milestones, and budget allocations. Approval authority 
rested with the NASA Headquarters Program Director. The Level I CCB 
also acted to resolve any matters referred to it by the Level II CCB. 

The Level II CCB approved changes to baselined requirement or 
configuration documentation which would impact two or more centers (or 
two or more project offices within a single center). Approval authority 
rested with the center-level Program Managers. All affected projects 
and centers evaluated proposed changes for impacts to their respective 
areas of responsibility, prior to Level II CCB action. This ensured 
that the total impact of a proposed change was fully understood, tech- 
nically assessed, and compatible with established requirements, costs 
and schedules. If a change affected primary mission objectives, experi- 
ment assignments, authorized funding, or major program milestones, the 
Level II CCB could either disapprove the change or refer it to the Level 
I CCB for disposition. 

The Level III CCB approved changes to baseline requirement or 
configuration documentation affecting a single project office within 
the jurisdiction of a single center. Approval authority rested with 
each Project Manager responsible for development of a major module or 
group of experiments. 

The Level IV boards, often informally at a hardware contractor's 
facility, controlled discretionary internal changes not affecting para- 
meters controlled at higher levels. 

2. Change Integration Working Group (CIWG) . The CIWG included 
representatives of the various technical systems disciplines and systems 
engineering and integration, and performed a screening function for the 
CCBs throughout the premission phase of the program. This group proved 
to be a primary tool for ensuring that the early design was well coor- 
dinated. 


3. Conf iguration Change Integration . A configuration management 
support group was established at each involved center to maintain an up- 
to-date status of interfacing hardware and documentation and to process 
requested changes. This group coordinated all proposed changes to en- 
sure that the interests of all interfacing organizations had been con- 
sidered. This function was referred to as configuration change inte- 
gration. It included receipt of proposed changes, coordination with 
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all affected organizations to determine total impact of the change 
(including cost and schedule), submittal to the appropriate CCB for 
action, and maintenance of overall configuration status. , 

B. Configuration Control Operation 

Changes to documentation and to hardware prior to baselining 
were controlled initially by the originator or the hardware developer. 
Once baselined, full configuration change control was implemented. 

The proper intercenter experiment change process is illustrated in 
figure 9. 

Necessary changes were identified in various ways: by con- 

tinuing compatibility assessment of the related documents, by the 
respective hardware milestone reviews, '-during iihatidwate deva Iopmeut , 
testing and manufacture, or by the addition or deletion of experiments 
during the program. The changes were generally Initiated either by 
the hardware developer or by the Integration Center support groups. 

If initiated by the hardware developer, an Engineering Change Proposal 
(ECP) was prepared to define the change and its impact to the hardware, 
systems, specifications, interface documents, cost and schedule. The 
preliminary ECP was submitted to CIWG by the originator, and was re- 
viewed for impact on program documentation by the compatibility analysis 
support group, and technically coordinated with the affected Pis u! 
and others as necessary. If incompatibilities were identified, an 
Engineering Change Request (ECR) and supporting change documentation 
were prepared. The ECR was an adaptation of the ECP for use primarily 
with program documents and specifications. The ECP, ECR and supporting 
documents formed a total package which presented all the change impacts 
for CCB evaluation. The approval, approval with changes, or disapproval 
by the CCB chairman was implemented by a Configuration Control Board 
Directive (CCBD). 

Changes were also initiated by the Integration Center (through 
the support groups) when incompatibilities were identified. In this 
event, the ECR was prepared and submitted to the CIWG for subsequent 
CCB action. The hardware developer received and analyzed the ECR for 
impact and, if an impact was identified, prepared an ECP to define it. 
The ECP and the ECR were then processed by the CCB, as above. 

The CCBD resulted in the preparation of Change Orders or Supple- 
mental Agreements for transmittal to the affected contractor (s) or Pro- 
ject Offices, directing the incorporation of the change into the docu- 
ments and hardware. Document changes were incorporated and distributed 
by the document custodians. 
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C. Complete Change Package 


It is essential that any change proposal identify all the 
hardware and documentation (at the same or other levels) which may be 
affected thereby. Accordingly, when a change was initiated from any 
source, the Integration Center formally conducted a change impact 
assessment. This assessment identified impacts to all interfacing 
hardware and documentation that might be affected. A checklist was 
used to identify the areas to be investigated. The changes were 
precoordinated with all affected organizations by the Integration 
Center before the CCB meeting. Thus the Integration Center was able 
to prepare a complete and coordinated change package for assessment 
at the CCB meeting. The Integration Center was uniquely qualified 
to perform this function and, by so doing, assured completeness and 
consistency of format and relieved other affected organizations of 
the need to expend resources to perform this task. Use of this 
technique greatly expedited CCB control of experiment-related changes 
at MSFC during the later stages of the Skylab Program. 

RECOMMENDATION: Utilize the "Complete Change Package" 

concept and precoordinate change packages with all 
appropriate disciplines prior to presentation to the 
CCB. NOTE: Configuration control cannot wait for 

each organization to finalize its document changes 
before acting on a proposal. The CCB Directive 
documenting a decision will specify any modifications 
to the change proposal that are considered necessary 
by the CCB. Document update pages implementing the 
CCB direction can then be prepared and distributed 
by the responsible organizations. 

D. Configuration Control Milestones 

Configuration control closely followed the hardware development 
milestones. Following the PRR for each experiment and module, the re- 
quirements documents were baselined and thus came under CCB control 
for changes. After PDR the documents that defined the approved design 
approach were controlled by the CCB. Likewise, followinggCDR, the 
approved detail design and test specifications came under CCB control. 

When two or more development activities took place in parallel 
(such as experiment and module development) there were three key Level 
II CCB functions that permitted these activities to proceed smoothly. 
The first occurred following the development PRRs, when the ERDs were 
placed under Level II control, even though they had been baselined 
previously at Level III. This allowed assurances to both developers 
that their design approaches were based on firm requirements, i.e,, 


43 



bhat chsngis to intcrf see rc^uirfimcnts would be minimized snd nficfisssry 
changes identified to all. concerned. The second function occurred 
during the design period prior to PDR, when the ICDs prepared by the 
module center had to be coordinated with the EDC to ensure mutual 
agreement on the interface details# These preliminary XCDs were then 
baselined at PDR, at which time they came under Level II control. 

With Level II ICDs, the developers could continue their detail designs 
with assurance of having firm interface agreements. The third major 
CCB function at Level II was control of the TCRSDs, which allowed the 
Module Development and Launch Operations Centers to prepare their 
detailed test procedures for testing the integrated systems. 
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SECTION X. SPECIAL DISCIPLINES 


Requirements established by specification for safety, reli- 
ability, maintainability and quality assurance affected all phases 
of the program and were necessary to assure mission success. Inter- 
related with these requirements, specific attention was focused on 
crew systems (i.e, , man/systems integration, or ''human engineering") , 
materials compatibility, contamination control, and various other 
systems-oriented disciplines. The impacts of these special disci- 
plines upon an individual experiment were influenced to some extent 
by the criticality of that experiment's potential failures. 

Experiments were categorized in the EIS according to the 
criticality (severity) of potential effects that could be produced 
by their worst-case failure modes. Criticality category identifica- 
tions varied between centers, but were generally consistent with the 
following basic definitions: 

Category 1 (or I) - Adversely affects personnel safety 
(flight or ground). 

Category 2 (or II) - Causes loss of a primary mission 
objective but does not adversely affect personnel 
safety (includes unscheduled termination of launch or 
mission). 

Category 3 (or IIIA) - Hay cause loss of a secondary 
mission objective but does not adversely affect per- 
sonnel safety or preclude the achievement of a primary 
mission objective. 

Category 4 (or IIIB) - None of the above; generally 
applicable to relatively passive experiments with 
very simple interfaces. 

RECOMMENDATION: Standardize criticality category 

and sub-category designations to be used by all 
program elements. 

The criticality category influenced the scope of the safety, 
reliability, quality assurance and test programs at the experiment,, 
module and overall program levels. Increased safety margins. 
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special design features, increased inspections during fabrication 
and assembly, and special tests to ensure existence of adquate mar- 
gins are examples of considerations given to experiments that had 
high-risk failure modes. The worst-case classification was applied 
without regard to probability of occurrence. 

A. Safety 

To ensure that hazards were identified and resolved throughout 
the program, the development centers required formal or informal im- 
plementation of safety program requirements for each end item. This 
program assured that methods were adequately implemented for identifi- 
cation and either elimination or control of potential hardware hazards 
that could result in injury to personnel or damage or loss of flight 
or ground hardware. Hazard Analyses were performed to identify, and 
offer solutions for, hazards that could result from failures, normal 
or emergency equipment operations, environments, personnel errors, 
or design characteristics, A "System Safety Checklist" (Reference 10), 
containing specific design criteria applicable to flight and ground 
hardware, lias been developed to assist new programs in the appli- 
cation oi saf ety -related experience. 

B. Reliability 

Integral to the design and development process was the evalua- 
tion of hardware reliability through analysis, review and assessment. 

A Reliability Plan was prepared for each end item, describing how the 
reliability requirements were to be implemented and controlled. 

Hardware failure modes were defined in FMEAs . Based on the results 
of the FMEAs, a Critical Items List (CIL) was prepared, which included 
a summary of single failure points and critical redundant (backup) com- 
ponents in life- or mission-essential equipment. In addition, design 
criteria were provided for the reliability of each subsystem. Reliability 
testing per se was generally not done; however, in certain very critical 
cases, some lifetime testing was conducted. After the hardware was 
fabricated, a system of providing information on unsatisfactory condi- 
tions or anomalies was utilized to keep abreast of reliability goals. 

C, Ma Lnta Inab 11 Lty 

The requirements for maintainability are closely associated 
with reliability and safety requirements during all program phases, 
with the major effort concentrated in the design phase. The princi- 
pal elements of maintainability assurance are: 1) provide design 

parameters (e.g., mean-time-to-repair , fault detection and isolation, 
limited lifetime items); 2) analysis of design; 3) design review 
participation; 4) data on maintainability; and 5) verification and 
demonstration of the maintainability. 



To the extent practicable, experiments were designed for 
accessibility, replaceability and serviceability during ground opera- 
tions. Skylab's original design philosophy specifically minimized 
in-flight maintenance as a design consideration. The rationale for 
this decision was quite logical in the circumstances. Inadequate 
data existed at that time on the astronauts 1 ability to perform com- 
plex tasks in space, or on the crew time, workshop space and weight 
budget that would be available. Thus extensive reliance upon in- 
flight maintenance, rather than designing for high inherent relia- 
bility, would have involved high risk. Actually, as the program 
matured, some minimal in-flight maintenance provisions were found to 
be essential, and were added. During the actual missions, however, 
in coping with unforeseen anomalies, the astronauts demonstrated 
excellent capabilities in this respect, even with improvised tools 
and in extravehicular activity (EVA). 

RECOMMENDATION: Design future manned space hardware 

to permit a much greater degree of in-flight mainte- 
nance, including EVA. Provide appropriate on-board 
spares, crew training and supporting documentation 
for maintenance tasks. 

D* Quality Assurance 

A Quality Assurance Program was implemented to ensure that 
all necessary actions were taken to provide confidence that the 
experiment would perform satisfactorily during flight. The quality 
program provided methods for detecting, documenting and analyzing 
deficiencies, system incompatibilities, or trends that could have 
led to any unsatisfactory quality of the experiment hardware. 

At all sites (development, integration, launch, mission 
operations), a general method was used for reporting all anomalies 
(failures and unsatisfactory conditions) relating to flight, test, 
simulator or training hardware. The reports identified the anomaly, 
where it had occurred, and the corrective action required. All 
participants (quality, engineering, test, NASA, etc.) concurred in 
the corrective action by signature. Within this formal method of 
tracking anomalies and recording their solutions, quality assurance 
personnel were responsible for verifying that the anomaly occurred 
as stated and that corrective action requirements were adhered to. 

A Failure Analysis was performed, where necessary, to determine the 
cause of the anomaly and identify adequate measures that could be 
implemented to prevent its recurrence. A status was maintained on 
all open anomalies until they were satisfactorily resolved. 
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E.. Crew Systems 


Strong emphasis in the design, development and integration of 
Skylub experiments and modules was placed upon man/systems Integration 
and human engineering, to ensure efficient utilization of the ground 
and flight crews' capabilities in the applicable environments. Man/ 
system design criteria were established for ready accessibility and 
identification, convenient arrangement, and ease of operation of ex- 
periments and cluster systems equipment. General cluster habitability, 
fixed and portable illumination, controls and displays, mobility aids 
and restraints, stowage, and provisions for extravehicular activities 
received particular attention. 

High-fidelity mock-ups and/or training hardware were utilized 
to conduct numerous formal reviews and informal walk-throughs by 
astronauts, Pis, and integration personnel during the development 
and integration phases. The C 2 F 2 tests were conducted on flight hard- 
ware as a part of acceptance tests and prelaunch checkout. Walk- 
throughs were also extensively used during the missions to check out 
new or revised operational procedures before transmitting them to the 
flight crew. Extraordinary activities involving EVA (e.g., deployment 
of a damaged solar panel) were rehearsed in the MSFC Neutral Buoyancy 
Simulator. 

Postflight evaluation of Skylab crew systems hardware is docu- 
mented in Reference 11. Additionally, Reference 12 was prepared to 
provide new and more clearly defined design criteria, based on Skylab 
experience, for use on future programs. Experiment -related lessons 
learned are included in the recommendations of Sections IV, V and VII, 
and in Appendix D, 


F- Materials Program 

Skylab policy for controlling materials selection, test and 
evaluation required that each Development Center Program Office prepare 
an implementation plan and Identify an individual materials specialist 
to serve as focal point for the center's materials program. Intercenter 
coordination was accomplished by a materials intercenter working group, 
w hicl». exchanged pertinent information, test data and deviations, and 
reconciled differences between the centers. Hardware developers were 
required to submit appropriate materials and parts lists, under their 
respective Reliability Plans. 

The Skylab materials program placed particular emphasis on 
reduction of fire hazards in the oxygen-enriched spacecraft atmosphere, 
through the use of nonflammable materials wherever feasible, and 
rigidly controlled usage of any necessary flammable materials. Other 


48 . 



important materials characteristics assessed were toxicity, odor, 
outgassing, offgassing, and flaking or powdering tendencies of paints 
and coatings. Materials information and test data provided signifi- 
cant inputs to the in-flight contamination control program. 

These activities on Skylab resulted in the preparation and 
release of a new OMSF material evaluation criteria document, 

NHB 8060,1, Although released too late for formal implementation on 
Skylab, NHB 8060.1 is understood to be a requirement for current OMSF 
programs . 


G* Contamination Control 

Hardware cleanliness monitoring prior to launch is a quality 
assurance function, amply covered by specifications and conventional 
quality control methods imposed on Skylab, However, analysis and 
control of the contamination that can occur in and around an orbiting 
spacecraft emerged as an important new discipline that warranted 
status approaching that of a major functional system. In-flight con- 
tamination, internal or external to the spacecraft, presented potential 
problems for nearly all experiments and cluster systems, notably those 
involving critical optics or other operational surfaces, 

A Contamination Control Working Group, including 
representation from MSFC, JSC, KSC, the Pis and contractors, was 
established at the Integration Center to conduct, coordinate and 
manage these efforts. Potential contamination sources were identified 
and quantitatively defined with the help of extensive materials testing. 
Experiment and system sensitivities to contamination were determined. 
Rigorous analyses, supplemented by comprehensive systems ground test- 
ing, were conducted to develop mathematical models of the performance 
of the sources and thereby predict in-flight contamination levels. 
Recommendations were made for design and operational procedure 
criteria and changes to minimize contamination effects (e.g., proper 
timelining of experiment exposure or operation In relation to various 
sources such as reaction control system firings and overboard venting) . 
Instrumentation was flown, such as quartz-crystal microbalances to 
monitor mass deposition rates and cloud brightness monitors for the 
induced atmosphere around the spacecraft. Flight data from these 
monitors and from certain experiments was used to validate and improve 
the prediction models 1 accuracy. The major sources of in-flight con- 
tamination, as predicted, were materials outgassing and reaction 
control system firings. The total Skylab experience clearly demon- 
strated the necessity for, and the validity of, these measures. 
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A detailed description and evaluation of the Skylab contamina- 
tion control program is available in Reference 13# Some experiment - 
related design considerations are identified in Appendix D. 

RECOMMENDATIONS: Implement rigorous and comprehensive 

measures for in-flight contamination control early in 
any new program, particularly where optical experiments 
are involved. Integrate the degradation effects of all 
contributory systems into the program design criteria 
on a level comparable to the major functional systems. 
Investigate new techniques for in-flight cleaning of 
accessible and remote optics, 

H. Other Special Disciplines 

Various other Skylab systems engineering activities influenced 
experiment development and integration. 

i* Elect romagnetic Compatibility . An intercenter/contractor 
Electromagnetic Compatibility (EMC) Working Group monitored compliance 
with the Skylab requirement that hardware be free of adverse electro- 
magnetic interference (EMI) under operational conditions. EMC 
compliance was established during the design phase and demonstrated 
predominantly by component-level testing, where circuit analysis was 
not considered adequate. A minimum of EMC testing was conducted at 
the module level to confirm the lower-level results. The EMC Working 
Group reviewed all pertinent designs, analyses, tests and waivers. 

No major EMI problems were encountered during the Skylab missions. 

2* Corona Suppression . A management-supported, program-wide 
effort to emphasize corona prevention was the key to success in this 
area. Corona specialists conducted frequent reviews of designs and test 
plans with their originators. This effort proved sufficient to minimize 
the degree of testing required and the rework of test failures that 
occurred, while maximizing the assurances gained. No serious loss 
of data or system failure due to corona effects occurred during the 
Skylab missions, 

Sneak Circuit Analysis . A sneak circuit analysis was 
performed on the integrated electrical systems to assure a low proba- 
bility of undesired current paths. A computer was used to help 
develop a simplified schematic of Skylab circuits for evaluation. 

This analysis verified electrical interfaces and provided valuable 
source material Cor checking operational documentation and for 
investigating real-time operational anomalies and workarounds. 

The program was successful in identifying 44 sneak circuits, plus 
a number of unnecessary components and documentation errors. 
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SECTION XI. PUBLIC RELATIONS 


Public awareness of program objectives, progress and benefits 
is an important obligation for NASA, which must be shared by the 
scientific investigator. Different approaches for public relations 
were required for the various experiments, depending upon an experi- 
ment's public appeal, the public's awareness of the Principal Investi- 
gator, and their ability to comprehend the science and potential 
applications of the experiment. 

A. NASA Public Affairs Office 

Each NASA center maintains a Public Affairs Office (PAO) , with 
established contacts for releasing space-oriented news to the media. 
Standard public affairs releases, consisting of NASA photographs with 
captions and prepared news stories, were released to the national news 
services. These releases normally contained only general background 
experiment information. 

Press conferences which required the Pi's participation were 
arranged periodically. They were generally scheduled for periods of 
peak public interest in the experiments (e.g., immediately prior to 
launch, following experiment performance or return of flight data, 
or to present results of flight data analysis). These briefings 
were held where the space-oriented press was gathered; at the launch 
center for launch, and at the operations center during mission opera- 
tions. Often a press conference presentation led to a private inter- 
view with a newspaper, periodical, or news service reporter. 

The press is primarily interested in results which can easily 
be understood by the public, i.e., the "biggest", the "best", or the 
"first." It was extremely helpful when the PI played an active role 
in releasing photographs of returned data with lucid explanations of 
the observable scientific phenomena. Scientific analysis was not 
required, or even desirable, in these press releases; simply a state- 
ment of what occurred and its potential significance. The objective 
of press briefings and press releases is to achieve public awareness, 
rather than public education. An active interplay or established 
liaison with the PAO assured the PI that accurate experiment informa- 
tion was being released, while the PAO was guaranteed interesting, 
newsworthy releases. 

RECOMMENDATION: Statements for public release should 

not be issued without prior program approval. 



B. Educational Programs 


Various educational programs initiated by NASA may require 
participation by the PI and/or experiment development or integration 
personnel. The following educational aids can be produced by NASA 
with limited participation required from these personnel. 

o Film Clips - Ten-minute motion pictures can be filmed 
of the PI explaining and demonstrating his experiment 
and the application of its results. These films are 
useful in providing program personnel with a more 
thorough understanding of the experiments, or as pres- 
entations demonstrating the state-of-the-art of space 
research to science students. 

o Educational Aids - Science educational aids can be 

prepared to describe groups of experiments, the appli- 
cation of basic principles of science and physics to 
execute the experiments, and the scientific value of 
the results. 

o Displays - Visitor center or museum- type displays can 
be distributed to visually stimulate the public's 
interest in space technology. 

o Postmission Historical Texts - Books printed after 
mission completion, with extensive use of mission and 
experiment photographs, can provide an informative, 
nontechnical presentation of mission/experiment oper- 
ations and results. 

Many different types of documents and presentations may be 
produced for educational purposes. These are the principal ones 
which will require a degree of cooperation and information from 
experiment personnel. 
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' DOCUMENTATION 


The principal experiment -related development, integration and 
mission operations documents required and utilized on the Skylab pro- 
gram are described in this Appendix. A documentation tree illustrating 
their primary interrelationships is shown in figure A-l. All documents 
were subordinate to the OMSF Skylab Program Specification, SE 140-001-1, 
which was the top-level technical specification for major program func- 
tional and performance requirements. 

A. Experiment Development Documentation 

The approved Experiment Implementation Plan (EIP), as described 
in Section III.C.l, provided the initial experiment definition, from 
which formal development documentation was derived. 


An OMSF "Experiment General Specification for Hardware Develop- 
ment" (EGS) identified requirements to be selectively imposed upon ex- 
periment developers, at the discretion of the Experiment Development 
Center. Considerable flexibility was permitted in EGS Implementation 
(depending upon the experiment's complexity and criticality) to mini- 
mize development costs within the constraints of crew safety and mis- 
sion success. As an EDC , JSC imposed its own "Experiment Hardware 
General Requirements Document" (EHGRD) , which generally paralleled EGS 
requirements but differed in some significant details. Specific devel- 
opment documentation requirements identified in these two specifications 
were similar, except as otherwise noted herein. 

RECOMMENDATION: Establish and maintain uniformity 

of requirements among diverse experiment developers 
by selective implementation of a single coordinated 
general requirements specification across all pro- 
gram elements. 


Development documents were categorized by the cognizant EDC 
as: Type I, to be submitted for approval; Type II, to be submitted 

for review; or Type III, required to be available upon request, but 
not formally submitted. The Type I category was generally limited 
to documents that defined and/or controlled major elements of program 
cost, schedule, or performance. 


Management Plan. At the outset of the development effort 
a Management Plan was prepared by the ED for EDC approval, defining 
the management organization and procedures to be used during develop- 
ment of the experiment hardware and GSE , It defined the responsibilities 
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and controls to be established and maintained throughout an integrated 
development effort, covering all hardware and GSE for which the developer 
was responsible. The plan contained the following sections: 

o General Management - defining the management structure, 
responsibilities and controls for the overall 
development effort 

o Quality Assurance - defining a Quality Program Plan 
and a Contamination Control Plan 
o Reliability Plan 
o Configuration Management Plan 
o Test Management Plan 
o Logistics Support Plan 
o Manufacturing Plan 

o Development Schedule - defining detailed schedules for 
the design, manufacturing and test efforts, includ- 
ing all related configuration management reviews, 
documentation and hardware deliveries 
o Nonmetallic Materials Plan (EHGRD only) 
o System Safety Plan (EHGRD only) 

2. Configuration Management Documents 

a. End Item Specification. The ED was required to pre- 
pare and maintain a detailed End Item Specification (EIS) for each 
type of experiment hardware identified in his Statement of Work (i.e., 
flight, mock-up and training hardware, and GSE). The EIS contained 
the total requirements for the development program and formed the 
technical basis for the contract between the ED and EDC . Specifica- 
tions were prepared on a paragraph-by-paragraph deviation basis to 
the EGS or EHGRD. The flight hardware EIS was prepared and approved 
before starting any development effort; minimum inputs for its prepara- 
tion were the experiment proposal, EIP, and compatibility assessment. 

The flight hardware EIS covered also the backup, qualification test, 
and flight-type training hardware, which were required to be identical 
in configuration with the flight article. The EISs for other hardware 
were generally prepared on a deviation basis from the flight hardware 


The EIS outline, as prescribed by the EGS, is shown in Table 
A-I. |_NOTE ; The JSC EIS, as per the EHGRD, was essentially identical 
through the area of Performance and Design Requirements, but thereafter 
included more detail in the areas of Quality Assurance, Reliability, 
Verification, Configuration Management and Documentation. JSC utilized 
a separate Configuration Specification as the control document for hard- 
ware development, in lieu of the Part II EIS .J 

After initial approval, specification changes could be incor- 
porated only through CCB-approved Engineering Change Proposals (ECPs) 
and Specification Change Notices (SCNs) . 
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TABLE A-I . END ITEM SPECIFICATION OUTLINE (PER EGS) 


PART I. 

PERFORMANCE /DESIGN REQUIREMENTS 

1 . 

SCOPE (including Criticality Category) 


i.i 

Changes 


2. 

APPLICABLE DOCUMENTS 

3. 

PERFORMANCE 

AND DESIGN REQUIREMENTS 


3.1 

Performance 



3.1.1 

Functional (Overall System; Mechanical, Electrical/ 




Electronic and Other Subsystems) 



3.1.2 

Operability (Reliability, Maintainability, Useful Life, 




Natural and Induced Environments, Transportability, 
Human Engineering, Safety) 


3.2 

Interface Requirements I 



3.2.1 

Flight Hardware (Flight Vehicle, Other Experiments, 




Ground Communications, Flight Crew, Mission, GSE, 
Facilities) 



3.2.2 

Zero Gravity Type Training Hardware 



3.2.3 

Neutral Buoyancy Type Training Hardware 



3.2.4 

Simulator Type Training Hardware 



3.2.5 

ICD List 


3.3 

Design 

and Construction 



3.3.1 

Mechanical 



3.3.2 

Electrical and Electronic 



3.3.3 

Fluid (Gas and Liquid) 



3.3.4 

Debris Protection 



3.3.5 

Cleanliness 



3.3.6 

Test Provisions 



3.3.7 

Single Failure Points 



3.3.8 

Redundancy 



3.3.9 

Selection of Specifications and Standards 



3.3.10 

Materials, Parts and Processes 



3.3.11 

Standard Parts 



3.3.12 

Fungus Resistance 



3.3.13 

Corrosion Prevention 



3.3.14 

Interchangeability and Replaceability 



3.3.15 

Workmanship 



3.3.16 

Electromagnetic Interference 



3.3.17 

Identification and Marking 



3.3.18 

Storage 



3.3.19 

Pyrotechnic Devices 

4. 

TEST /PRODUCT ASSURANCE REQUIREMENTS 


4.1 

Verification Matrix 


4.2 

Test Types 



4.2.1 

Development 



4.2.2 

Qualification 



4.2.3 

Reliability 



4.2.4 

Other Tests (Integrated Systems, Flight Verification, 




Post flight) 


4.3 

Rejection J( 
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TABLE A-I. END ITEM SPECIFICATION OUTLINE (PER EGS) (Continued) 


5. DATA LIST 

6. PREPARATION FOR DELIVERY 

7 . NOTES 

PART II. PRODUCT CONFIGURATION REQUIREMENTS 

1 . SCOPE 

1.1 Product Configuration Baseline Acceptance 

1.2 Changes 

2. APPLICABLE DOCUMENTS 

3 . PRODUCT REQUIREMENTS 

3.1 Performance 

3.1.1 Functional Characteristics 

3.2 Configuration 

3.2.1 Manufacturing Drawings 

4. TEST/PRODUCT ACCEPTANCE REQUIREMENTS 

4.1 Acceptance Matrix 

4.2 Test Types 

4.2.1 Acceptance 

4.2.2 Other Tests (Integrated Systems, Prelaunch) 

4.3 Rejection 

5. DATA LIST 

6. PREPARATION FOR DELIVERY 

6.1 Preservation and Packaging 

6.2 Packing 

6.3 Shipment 

7. NOTES 




b. Engineering Drawings. The ED prepared engineering 
drawings to control, by means of pictorial or narrative presentations, 
the physical and functional engineering requirements for each part of 
the hardware to be produced. The drawing tree progressed from the top 
assembly drawing to detail component and part drawings. They provided, 
directly or by reference, all data needed for use in conjunction with 
specifications, test procedures and reports, inspection procedures, 
acceptance and rejection criteria, processes, manuals, operational pro- 
cedures, safety precautions, surface cleanliness requirements, etc. 

The engineering drawings included: 

o All essential drawing information needed to permit an 

evaluation or a feasibility study of the proposed design, 
or to document the results of exploratory research or 
development effort . 

o Sufficient detail to enable evaluation and control of 
physical and functional design interrelationships of 
interdependent components, equipments, subsystems, 
systems, ground support equipment or facilities. 

o All drawing information necessary to support installa- 
tion, operation, maintenance and interchangeability 
during tests and operational use. 

o The necessary design, engineering, manufacturing and 
quality support information, directly or by reference, 
to enable the procurement, without additional design 
effort or recourse to the original design activity, of 
an item that duplicated the physical and performance 
characteristics of the original design. 

c. Technical Reports. The results of studies and analy- 
ses performed during the development effort were documented in tech- 
nical reports. The reports covered load analyses, stress analyses, 
trade-off studies, etc., and were not standardized in format. 

d. Review Minutes, Minutes were prepared for each PRR, 

PDR and CDR. The minutes for each review consisted of two parts. 

Part A provided an immediate record of the review proceedings and 
included all items requiring post-review actions. Part B was pre- 
pared after the final disposition of all Part A action items, and 
reported the final disposition of each* (See Appendix C.) 

e . C onfi gurati on In sp ec t ion (Acceptance) Revie w Report. 

A C1R Report was prepared for each acceptance review (see Appendix C). 
Xt provided a record of the review results, including: 
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o Action items with their disposition 
o Waivers or deviations authorized 
o Shortages authorized 

o Copy of the completed Form DD250 (Material, Inspection 
and Receiving Report) 

3, Quality Assurance Documents . 

a. Acceptance Data Package, The ED prepared an Acceptance 
Data Package (ADP) for each deliverable hardware end item. After deliv- 
ery, the ADP stayed with the hardware and was updated to reflect subse- 
quent usage. The hardware custodian was responsible for maintaining 

the ADP current as required. The package included but was not neces- 
sarily limited to the following: 

o Equipment logs (see item A.3.c) 

o Engineering drawings down to the replaceable component 
level (see item A.2,b) 

o Inventory of serialized components, including part number, 
name, serial number, and the associated experiment 
hardware subsystem 

o Report of actual weight and center of gravity 
o Operating, Maintenance and Handling (OM&H) procedures 
(see item A. 7) 

o Calibration Data Report (see item A.5.e) 
o Listing of all Material Review Records (see item A.3.b) 

o End Item Specification, Parts I and II or Configuration 

Specification (see item A. 2. a) 
o Certification that the hardware had been cleaned in 

accordance with the Contamination Control Plan (see 
item A. 1) 

o Failure Reports and Failure Analysis and Corrective 
Action Reports (see items A.3,d & e) 
o Configuration Inspection (Acceptance) Review Report 
(see Item A.2.e) 

b. Material Review Records. A Material Review Board 
(MRB) at the hardware development site wus composed of ED design 
engineering and quality representatives and the EDC's designated 
quality representative. The MRB reviewed and determined disposition 
of articles or materials submitted by ED quality assurance as "non- 
conforming" with applicable drawings, specifications or other require- 
ments. Accurate Material Review Records of MRB actions. Including 
assurance of effective remedial and preventive actions, were main- 
tained and incorporated in the appropriate hardware ADP. 

c * Equipment Logs , An Equipment Log was prepared and 
maintained for each major hardware component, subsystem, and system 
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to document the continuous history of the item. Entries included, but 
were not limited to, the following: 1) date of entry, 2) identity of 

test or inspection, 3) environmental conditions, 4) characteristics 
investigated, 5) parameter measurements, 6) identity of instrumentation 
used and calibration dates, 7) record of all storage, operating, and 
test times, and listing of time/cycle critical items, 8) cumulative 
number of duty cycles, 9) discrepancies, 10) repair and maintenance 
records, 11) record of pertinent unusual or questionable occurrences, 

12) action taken to formalize quick fixes, 13) identity of individual 
making entry. The equipment logs, as part of the ADP, were available 
at all times for inspection and review with the equipment. 

d. Failure and Unsatisfactory Condition (UC) Reports. 
Failure and UC Reports were prepared by the developer for any failure 
where a system, subsystem, component or part was unable to perform its 
required function under the specified conditions for the specified 
duration. Each report contained the part number, name of part, serial 
number, part manufacturer, date problem was first detected, test being 
conducted when the problem occurred, conditions at time of problem, 
problem description, problem cause (if known), and any other informa- 
tion considered pertinent. 

e . Failure Analysis and Corrective Action Reports. 

Failure Analysis and Corrective Action Reports were prepared by the 
developer for each reported failure. Each report referenced the Failure 
Report, defined the method of analysis, documented the results, defined 
the action(e) necessary to prevent recurrence of the failure, and 
included justification for the selected action. If the proposed cor- 
rective action required a change to the baseline configuration, the 
failure analysis and proposed corrective action were submitted with 

an ECP, After approval of the change proposal, the approved Failure 
Analysis and Corrective Action Report was submitted, indicating the 
need for reverification and containing provisions for signature close- 
out of the item. 

4* Reliability Documents , 

a. Failure Mode and Effects Analysis Reports. FMEA 
reports were prepared for each end item to identify critical failure 
areas and remove susceptibility to such failures. These analyses were 
performed on each component of the end item and each potential failure 
was categorized according to its probability of occurrence and conse- 
quent effect on mission success (see Criticality Categories, Section 
X). These reports served as an aid in proportioning the effort 
required for corf cc Live design action and reliability control. Each 
report included a Single Failure Point Summary, a Hazards Summary and 
Reliability Logic Block Diagrams. The single failure point summary 
summarized all Category 1 and 2 single-point failure modes by identi- 
fying the: 1) item name, 2) failure mode, 3) effect of failure upon 
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the system, 4) criticality of the failure, 5) means of detection, 

6) required corrective action, and 7) justification or rationale of 
acceptance if corrective action was not implemented. The Hazards 
Summary identified and categorized catastrophic or critical hazards 
in environment, hardware, test, training, operational procedures and 
interface conditions and discussed steps to relieve these hazards. 

The Reliability Logic Block Diagrams showed the functional inter- 
dependencies among the system components so that the effects of a 
functional failure could be readily traced through the system. All 
redundancies or other means for preventing failure effects were shown 
as functional blocks or notes. 

b . Electrical. Electronic and Electromechanical Parts 

List. An EEE Parts List was prepared to identify all EEE parts in 
use, and included as a minimum the following: 1) generic part, type, 

name and number, 2) common designation, 3) manufacturer's name, 

4) manufacturer's part number, 5) package type, 6) specification name 
and number, 7) quantities used per replaceable assembly and identifi- 
cation of replaceable assembly, 8) limited life part restrictions, 
and 9) qualification methods and status. 

c. Materials List. A Materials List was prepared, ldenti- 
fying all nonmetallic materials in use, and also containing a summary 
of metallic materials used that reflected any recognized flammability, 
toxicity or odor hazards inherent in the design through use of metal- 
lic materials. The Materials List included as a minimum the following: 
1) part number, 2) major assembly part number, 3) generic identifica- 
tion, 4) material manufacturer, 5) material specifications, 6) trade 
name or commercial name and catalog number, 7) usage category, 8) weight 
per usage, 9) exposed surface area, and 10) method of verification and 
status. 


5. Test Documents 


a » Verification Plan. A separate verification plan for 
each end item was prepared by the ED and submitted for approval at 
the PDR. It defined the verification methods (similarity, analysis, 
inspection, demonstration, validation of records, or test) to be used 
to verify that the end Item met each technical requirement in the EIS. 
For requirements to be satisfied by assessment, the plan described the 
specific types of analyses, inspections, etc, to be conducted (i.e., 
stress analyses, thermal analyses, radiographic inspections, etc), 
defined the objectives of these methods, and identified the documents 
that would contain the assessment. When a requirement was to be veri- 
fied by test, the Verification Plan defined: specific tests to be 

conducted; equipment components, parts, etc, to be tested; test objec- 
tives; locations where Lests were to be conducted; facilities and 
equipment support requirements; and time phasing of the tests. The 
test program was to provide only the minimum tests necessary, based 
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on Che criticality and complexity of the experiment. The entire 
spectrum of tests was analyzed as an integrated effort to minimize 
test requirements and prevent duplication. Testing was conducted at 
the highest feasible level of hardware assembly. For very simple 
experiments, the test plan, specification and procedure could be com- 
bined into the same document. 

b. Test Specifications. A Test Specification was pre- 
pared by the ED for each type of test defined in the Verification Plan. 
Each specification included, as applicable! test item nomenclature and 
identification; test objectives; quantity to be tested; test parameters 
or performance criteria, with limits or tolerances; acceptance and re- 
jection criteria; environmental conditions; hazardous operations or 
situations; reference to applicable safety standards, rules and regula- 
tions; allowable adjustment or maintenance operations; requirements for 
data recording, analysis, retest and reporting of test results; and 
test article disposition. 

c. Test Procedures. Test Procedures were prepared by the 
ED for each type of inspection and test defined in his test specifica- 
tions. The Test Procedures prescribed steps to be accomplished in 
detail and sequence, test equipment to be u^ed, calibration require- 
ments, layout and interconnection of equipment, safety practices (for 
equipment and personnel) to be observed and criteria for passing the 
test, including tolerances. Development test procedures were not sub- 
mitted for approval; however, all other (qualification, acceptance, 
etc) procedures were submitted for EDC approval. 

d. Test Reports. Test Reports were prepared for each 
type of test conducted. Qualification and acceptance test reports 
were submitted at the C1R for review of their validity and verifica- 
tion of satisfactory tests. The test report contained an evaluation 
of test data, a comparison of test results with test objectives and 
design and performance requirements, a listing of any associated 
failure reports, and conclusions based on the evaluation. The report 
in many cases also contained an annotated copy of the actual test 
procedure . 


e. Calibration Data Reports. Where applicable, a Cali- 
bration Data Report was prepared from acceptance test results and 
became a part of the ADP. These reports provided the actual calibra- 
tion data sheets for each measurement produced or displayed by the 
experiment. For each measurement the report included the following: 

o Descriptive title of measurement 

o Measurement number 

o Indicating device part number and serial number 
o Component part number and serial number in which the 
indicating device was installed 



o Original tabulation of actual calibration data points 

o Original graph of calibration data 

This information was used for data evaluation during integration testing 
and mission data reduction. 

6. Development Status Report . A Development Status Report 

was prepared by the ED to provide the status of the total development 
effort at each program milestone. The report was an integrated effort 
covering the development of all the ED's hardware, including GSE. It 
included, but was not limited to, the following: 1) schedule status, 

2) mass properties status, 3) quality assurance, reliability and system 
safety status, 4) spares status, 5) delivery status. 

7 . Operating. Maintenance and handling Procedures , The Opera- 
ting, Maintenance and Handling (OM&H) procedures were prepared by the 
ED and included in the ADP, to define all procedures required during 
both flight and ground usage. The procedures contained all instruc- 
tions for operation, servicing, maintenance, calibration, handling, 
cleaning, storage, packing and shipping. Any limited-life or time- 
critical items were identified and replacement cycles defined. The 
procedures included all diagrams, exploded views, sketches, text, etc, 
necessary to permit efficient procedure accomplishment. They also 
clearly indicated any step which, if not correctly followed, would 
result in serious injury to personnel or hardware damage, and gave 

the reason for such warning. The flight hardware OM&H normally con- 
sisted of three volumes. Volume I contained a general description of 
the hardware and its interfaces; subsystem functional description, 
operational and design characteristics, limitations and restrictions; 
and controls and displays. Volume IX contained the mission operational 
procedures for both normal and contingency operations, in a step-by- 
step checklist format that was used by the Mission Operations Center 
to prepare detailed checklists for the crew. Volume III contained all 
necessary procedures to accomplish ground operations, maintenance and 
handling of the hardware (including recovery operations if applicable); 
this volume was used by the Module Development and operations centers 
to prepare their detailed test and handling procedures. 

8. Data Request Form . The standard format for the DRF , the 
formal instrument for identifying experiment data requirements, is 
reproduced in figure A-2. Contents of the various blocks in the DRF 
are self-explanatory from their titles. 
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DATA REQUEST FORM 

Sky tab Program 


Roqaoit Contact 



Ori glnotor 


Han* 

O'gonliotlon 
phono 
$1 gnatvfo 


N«*"* 

Organisation 
phono 
}l gitaftro 


U«rC • Perm eft (October 1970) 


Ham* 

Organisation 

phono 

Signotura 


Organisation 

phono 

Signoturo 


FIGURE A-2. DBF FORMAT 
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B. Integration Documentation 


Integration documents were prepared to assure that the experi- 
ment interfaces with the program were satisfactorily provided. Begin- 
ning with the experiment concept, the requirements for program inter- 
faces were established and systematically compared with program capa- 
bilities. Requirement documents were prepared which in turn generated 
documents that defined the interfaces or identified how the requirements 
were to be satisfied. In general, these documents were prepared by or 
under the cognizance of the Integration Center or Module Development 
Center. Mission operational documentation, which also involves exten- 
sive experiment Interfaces, is treated separately in Section C. 

1. Compatibility Assessment . When the experiment concept was 
originally considered for approval, compatibility analysis was initiated 
by the Integration Center. It compared all experiment requirements to 
program capabilities and reported the compatible areas as well as incom- 
patible areas. Modification of proposed experiment requirements was 
often necessary to produce a compatible experiment. After experiment 
approval, the compatibility assessment became a recurring integration 
document covering total compatibility of all the integrated experiments. 
The review of major problems identified in the compatibility assessment 
was supplemented by bimonthly management review meetings held by the 
Integration Center and attended by representatives of the other centers 
Involved. At these reviews, the status of the problems was presented, 

a plan agreed to for their solution, and action items assigned (see 
Appendix B) , 

2. Experiment Requirements Document . After the experiment was 
approved, the EDC (or in some cases the Integration Center) prepared an 
ERD to specify the experiment requirements for module and program inter- 
faces. These interfaces could be of a physical nature (electrical, 
data, control, crew, thermal, mechanical, stowage, etc) or program 
interfaces (integration test requirements, number of mission data takes, 
recovery requirements, etc). The ERD was approved by the EDC and became 
a Level II baseline document following experiment and module PRRs. As 
the program proceeded, various ERD requirements became formalized in 
other Level II documents such as ICDs, TCRSDs, and MRD, and were de- 
leted from the ERD to avoid redundancy. Table A-II presents the stan- 
dardized ERD outline, as prescribed by an intercenter "ERD Instructions" 
document. 


3. Cluster Requirements Specification . Since Sky lab involved 
several modules, an overall integration specification for the assembled 
modules (cluster) was found necessary. This document, prepared by the 
Integration Center, was identified as the Cluster Requirements Specifi- 
cation (CRS) , and amplified the general performance and design integra- 
tion requirements of the Skylab Program Specification to ensure that 
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TABLE A-II. EXPERIMENT REQUIREMENTS DOCUMENT OUTLINE 


1 . EXPERIMENT DESCRIPTION 


1.1 Objective 

1.2 Concept 

1.3 Experiment Description and Function 

1.3.1 Experiment Equipment List 

1.3.2 Additional Supporting Equipment 

1.4 Relation to Other Experiments 

1.5 Cluster Requirements Imposed on Experiment 

2. MISSION ASSIGNMENT AND HARDWARE REQUIREMENTS 

2.1 Flight Assignment 

2.2 Location Assignment 

2.3 Hardware Requirements (Number and types of experiment end 

items) 

3. DATA REQUIREMENTS 

3.1 Preflight Data Requirements 

3.2 In-flight Data Requirements 

3.2.1 Experiment Measurement List 

3.2.2 Spacecraft Systems Measurement List (Housekeeping) 

3.2.3 Photographic Data Requirements 

3.2.4 Other In-flight Data Requirements 

3.3 Postflight Data Requirements 

3.4 Data Return Requirements 

3.5 Special Handling Requirements 

3.6 Analysis and Processing Support 

4. FLIGHT VEHICLE SYSTEMS REQUIREMENTS 

4.1 Structural and Mechanical Requirements 

4.1.1 Weight and Volume 

4.1.2 Dimensional Sketches 

4. 1.2.1 Stowed 

4. 1.2.2 Operational 

4. 1.2. 3 Post-Operational 

4.1.3 Mounting, Alignment and Orientation Requirements 

4.1.4 System and Equipment Modifications 

4.1.5 Plumbing Requirements 

4.1.6 Fluid Requirements (Gaseous and Liquid) 

4.1.7 Accessibility Requirements 

4.1.8 Observation Access Requirements 

4.2 Environmental Requirements 

4.2.1 Thermal Requirements 

4.2.2 Atmosphere Requirements 

4.2.3 Radiation Requirements 

4.2.4 Lighting Requirements 

4.2.5 Other Environmental Constraints 
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TABLE A-IX. EXPERIMENT REQUIREMENTS DOCUMENT OUTLINE (CONTINUED) 


4. FLIGHT VEHICLE SYSTEMS REQUIREMENTS (CONTINUED) 

4.3 Electrical Requirements 

4.3.1 Power and Voltage Requirements 

4.3.2 Power Profile 

4.3.3 Other Power Characteristics 

4.4 Instrumentation and Communications Requirements 

4.4.1 Telemetry System Requirements 

4.4.2 Timing System Requirements 

4.4.3 Ground Command Requirements 

4.4.4 Voice Communication Requirements 

4.4.5 Displays and Controls Requirements 

4.5 Interface Requirements 

4.5.1 Interface Schematic 

4.5.2 Interface Identification 

4.5.3 Existing Hardware Interfaces 

4.6 Expendable Equipment Disposal 

5. EXPERIMENT AND FLIGHT VEHICLE POINTING REQUIREMENTS 

5.1 Experiment Pointing Requirements 

5.1.1 Target Description 

5.1.2 Experiment Pointing Accuracy 

5.1.3 Allowable Experiment Rates 

5.1.4 Number of Performances 

5.1.5 Duration of Each Performance 

5.1.6 Time of Each Performance 

5.2 Flight Vehicle Pointing Requirements 

5.2.1 Orbit Requirements 

5.2.2 Spacecraft Orbital Location During Each Performance 

5.2.3 Reference Orientation 

5.2.4 Spacecraft Pointing Accuracy 

5.2.5 Allowable Spacecraft Rates 

5.2.6 Allowable Spacecraft Acceleration 

5.2.7 Spacecraft Maneuvers Required 

6. FLIGHT CREW OPERATIONS REQUIREMENTS 

6.1 Experiment Preparation Requirements 

6.2 Experiment Operation Requirements 

6.3 Post Operation Tasks 

6.4 Operation Schedule Constraints 

6.5 Crew Training Requirements 

6.6 In-flight Maintenance Requirements 

7. FLIGHT OPERATIONS REQUIREMENTS 

7.1 Flight Support Requirements 

7.1.1 Command List 

7.1.2 Support Requirements 

7.2 Recovery Support Requirements 
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TABLE A- II. EXPERIMENT REQUIREMENTS DOCUMENT OUTLINE (CONTINUED) 


8. 

POSTACCEPTANCE TESTING 


8.1 

Experiment/Module Integration Test and Checkout 1 



8.1.1 

Receiving, Inspection and Handling 



8.1.2 

Ground Personnel Participation 



8.1.3 

Integrated Test 

8. 1.3.1 Test Types 

8. 1.3.2 Test Locations 



8.1.4 

Facilities 



8.1.5 

Data Recording 



8.1.6 

Ground Support Equipment/Test Equipment 



8.1.7 

Services 



8.1.8 

Special Test Constraints 


8.2 

Prelaunch Checkout 



8.2.1 

Receiving, Inspection, and Handling 



8.2.2 

Ground Personnel Participation 



8.2.3 

Prelaunch Test and Activities 




8.2.3. 1 Test and Activity Types 

8. 2. 3. 2 Equipment Utilization 



8.2.4 

Facilities 



8.2.5 

Data Recording 



8.2.6 

Ground Support Equipment/Test Equipment 



8.2.7 

Services 



8.2.8 

Special Test Constraints 


8.3 

Ground 

Personnel Training Requirements 

9. 

RESUPPLY AND REACTIVATION REQUIREMENTS 


9.1 

Orbital Storage Requirements 


9.2 

Resupply Equipment and Materials 


9.3 

Reactivation Procedures 


9.4 

Special Requirements 

10. 

REPORTS OF 

EXPERIMENT RESULTS 
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all hardware would successfully function as an integrated system to 
accomplish mission objectives. In addition to the general requirements , 
the CRS addressed some specific requirements for primary functional 
areas (i.e., structural, attitude control, electrical, control and dis- 
play, communications and data, environmental control, crew, and caution 
and warning flight systems; ground systems; and payload requirements 
imposed on the launch vehicle). It also provided a comprehensive list- 
ing and description of all approved deviations to its technical require- 
ments . 


4. Interface Control Documents . Once experiment requirements 
had been baselined, immediate attention was given to providing the 
interface details. These details were documented by the Module Develop- 
ment Center in ICDs. Preliminary ICDs were reviewed and baselined at 
the experiment PDR. Three basic types of ICD were prepared for each 
experiment : 

o Mechanical /Environmental (weight, center of gravity, 
attachment provisions, structural loads, thermal 
environment, etc - see Table A-III); 

o Electrical (type of power, connectors, pin assignments, 
wire sizes, etc - see Table A-IV) ; 

o Instrumentation and Communication (number of data 

measurements, type, sample rate, etc - see Table A-V) . 

In addition to the experiment- to-module ICDs, GSE and facility ICDs 
were also prepared as necessary to define the experiment -to-GSE 
and GSE-to-f acility interface requirements, 

5. Module Specifications and Documents . Paralleling the 

experiment documentation, the Module Development Center prepared a 
Module End Item Specification, module FMEA, and various other inte- 
gration documents that incorporated experiment information. Typical 
of the latter were: the module Power Allocation Document, which inte- 

grated the electrical power requirements of the module systems and its 
installed experiments; module Measurements Lists, which identified and 
defined the instrumentation and communications services provided by 
the module; module Critical Items List (CIL), which summarized all 
Category 1 and 2 critical items within the module, including those 
identified for experiments; etc. 

6 . Experiment Integration Test Requirements and Specifications . 
As described in Section V.C, the Integration Center coordinated prepara- 
tion of an EITRS document which compiled postacceptance test require- 
ments of all the experiments, and provided source information for the 
module and integrated system TCRSDs . Figure A-3 shows the format of a 
typical EITRS page. 
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original page is 

OF POOR QUALITY 






effectivity I 

PAHA 



CONSIDERATIONS AND 






NUMBER 

TEST 

CRITERIA AND SPECIFICATDN 

CONSTRAINTS ' 

1 

MDAC 

ED 

wc 


ESC 

4.24.3.2*- 

6-4 

Verify the operation! of the Flanraabillty Timing 
cl.rcai.ts. 

ELAPSED light Illuminates after 10 seconds. 

With: 

SBG0BDS '* Iff’ 


E 

B 



4*24*3.2.- 

6-5 

Verify the operation of the FLAMMABILITY READY 
function. 

READY light illuminates. 

With: 

READY /RES FT READY 


X 

■ 


X 

4.24.3.2.- 

6.6 

Verify operation of the FLAIMABILITY Data 

Start function. 

Caere OB signal Indication at camera 
interfaces. Flood Light Illuminates, and 
28 ^ VPC at igniter for approximately 
3 seconds. 

With: 

DATA START "OK" 

(Momentary) 


X 

X 


X 

4.24.3.2.- 

6.7 

Verify that proper water pressure and flow rate 
is provided by M512 for M479. 

After approximately 10 seconds elapsed 
light flashes and Flood Light flashes. 
Capable of flowing water. 

GSE required. 





X 

4.24,3.3 

4-24.3.4 

Deleted 

Verify the pressure In the MPF. 

Wort Chamber GN^ pressure: 4.5 + 0.5 PSIA 

This will require backfilling 
the Work Chamber. 


X 



I 



High Voltage electronics section pressure. 









Ferflnorsl propane @25 + 1.0 PSIA 







4.24.3.5 

Verify Crystal Growth Storage Container 
power to container. 

At Crystal Growth Storage Container 
Test connector 28 ^ YDC 

At HA it. Flight Qoaliflable 
Growth Storage Container 
required. 




I 

X 




At ESC, Flight Unit required 
for VAB Test prior to closeout. 






4.24.3.6 

Verify ID THff notify Pi light function 

ID I5W ilbnsinates 

LO naff/ LAMP TEST switch to 
LAMP TEST 




■ 

X 

4.24.3.7 

Verify the operation of the Battery Discharge 
Indicator Light. 

DISCHARGE illuminates. 
0.90 + 0.05 AMP discharge 

Main Battery Circuit Breaker OH 
Battery Discharge Circuit 
Breaker ® 


X 





FIGURE A-3. EITRS FORMAT (SAMPLE) 














TABLE A-III. MECHANICAL /ENVIRONMENTAL ICD OUTLINE 


1.0 

Scope 


2.0 

Applicable 

Documents 

3.0 

Requirements 


3.1 

Functional Requirements 



3.1.1 

Environmental 




3. 1.1.1 Spacecraft /Launch Vehicle Imposed Environments 

3.1. 1.2 Experiment Required Environments 




3. 1.1.3 Experiment Imposed Environments 



3.1.2 

Interface Loads 

(Maximum Loads at the Attachment Interface) 



3.1.3 

Mass Properties 

(Weight, Moment of Inertia, Center of Gravity) 


3.2 

Procedural Requirements (If Applicable) 


3.3 

Physical Requirements 



3.3.1 

Mechanical (Drawing showing Structural Interface) 



3.3.2 

Envelope 



3.3.3 

Axes Definition 



3.3.4 

Alignment 


TABLE A-IVp ELECTRICAL ICD OUTLINE 


1.0 Scope 

2.0 Applicable Documents 

3.0 Requirements 

3.1 General 

3*1.1 Abbreviations 

3.1,2 Terminology 

3*1*3 Electrical Characteristics 

3.2 Interface Wiring 

3.2.1 Connector Designations 

3.2.2 Cable Pin Functions 


74 






TABLE A-V. INSTRUMENTATION AND COMMUNICATIONS ICD OUTLINE 


1.0 Scope 

2.0 Applicable Documents 

3.0 Requirements 

3.1 Telemetry 

3.1.1 Data Signal Characteristics 

3. 1.1.1 Analog Measurements 

3. 1.1. 2 Digital Measurements 

3.1.2 Signal Conditioning 

3.2 Commands 

3.3 Timing 

3.4 Correlation Data - (Measurement originating outside 
experiment, required during course of experiment operation.) 

3.5 Electromagnetic Compatibility 
3.5.1 Bonding 


7 # Test and Checkout Requirements and Specification s Documents. 
The module TCRSDs and the integrated system TCRSD were prepared by the 
Module Development Center and Integration Center. These TCRSDs defined 
the module and system acceptance requirements, specification criteria 
and constraints to be used in preparing the test procedures. The TCRSDs 
utilized the EITRS as the basis for experiment test requirements. The 
module TCRSDs were utilized at the module contractor's and. launch sites. 
The integrated system TCRSD was used only at the launch site. The TCRSD 
format was the same as the EITRS without the effectivity columns. 

8. Test Procedures . Module and integrated system testing was 
performed in accordance with detailed test procedures written by the 
Module Development Center or the Launch Center to satisfy the require- 
ments and specifications of the TCRSDs. The procedures contained a 
description of the test, test configuration, special test requirements, 
data requirements, test evaluation, and Btep-by-step test performance 
instructions. For experiment operating details, the OM&H manual de- 
livered with the experiment ADP was used. The EDC supported final 
preparation of these procedures by reviewing them prior to the test. 

An addendum to the test procedure contained a listing of all test 
anomalies, anomaly descriptions, troubleshooting steps and corrective 
action taken. 

9. Installation and Removal Procedures . Based upon the experi- 
ment OM&H manual, module integration plans and the ERD, the Module- De- 
velopment Center also prepared documents for handling, installing, and 
removing the experiments. These procedures contained, for each site, 
the environmental and handling constraints, drawings necessary for 
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showing complex processes (loading film, installing experiments, etc.), 
detailed steps for performing installation, removal and refurbishment, 
reference to all GSE/Facility ICDs, and a list of all GSE required. 

C. Mission Operational Documentation 

1. Operations Directive (Program Directive No. 43) . A series 
of formal directives was issued by the Program Director, and controlled 
at Level I, to amplify the Program Specification requirements in specific 
areas. Program Directive No. 43 officially identified program objectives, 
policies and requirements; described the various Skylab missions, their 
specific objectives and requirements; and identified mission assignments 
and scheduling instructions for the individual experiments. 

2. Mission Requirements Document . The MRD provided the basis 
for mission planning and design. It was prepared by the Mission Opera- 
tions Center, based upon the Program Specification, Operations Directive, 
ERDs, and Experiment OM&H manuals. It defined the integrated functional 
and performance requirements to achieve program and mission objectives. 
Many subsidiary mission documents were prepared to implement the MRD 
requirements. These documents could expand upon, but could not conflict 
with the MRD contents. 

The MRD contained a definition of the mission objectives, a 
mission profile description, launch date(s), orbital parameters and 
vehicle attitude capabilities. General ground rules relating to in- 
flight operations were prescribed for use in flight planning. The MRD 
also defined, for each experiment, the detailed test objectives (DTOs) , 
requirements, test conditions and types of data required for experiment 
accomplishment. The test conditions described the environmental limi- 
tations, pointing requirements, vehicle attitude stability, electrical 
tolerances and all other constraints pertinent to experiment operation. 

The MRD was updated and expanded In periodic review cycles, 
under Level II change control. 

3» Flight Plan . The Flight Plan, prepared by the Mission 
Operations Center, was a detailed schedule of all In-flight crew 
activities. It responded directly to the MRD and endeavored to satisfy 
all requirements and constraints specified therein. The scheduled 
activities for each crewman were laid out relative to a time base, 
uBing operation times which had been verified during crew training 
sessions. In addition, the summary timeline format (see figure A-4) 
provided a simultaneous display of related data such as day and night 
periods, beta angle, ground station contact times, vent times and tape 
recorder usage. 

The graphical presentation utilized in the Flight Plan facili- 
tated the identification of conflicting requirements and constraint 
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violations. Although not under formal change control, the Flight Plan 
was under continual revision, and each publication was widely distri- 
buted for review and comment. The information required to produce the 
Flight Plan was updated as required and stored in a data bank for use 
during the mission in the computer-controlled, real-time Flight Plan 
generation. 


4. Stowage List . Stowage lists were compiled and maintained 
by the Mission Operations Center to identify and track the proper loca- 
tion of all moveable equipment in the Skylab modules throughout the 
mission(s). The lists highlighted the article's Identification, weight, 
cumulative quantities launched and returned, and the planned stowage 
locations for launch, in-flight transfer, and return. A sample Stowage 
List format is reproduced as figure A-5. 

5. Flight Mission Rules . The Flight Mission Rules were a com- 
pilation of preplanned responses to possible in-flight contingencies. 
They were prepared before the missions, and attempted to anticipate 
anomalies which might occur during flight, together with appropriate 
corrective actions. These rules were designed to reduce the response 
time required to cope with anomalous situations during the mission. 

They were crucially important in those instances where a particular 
malfunction might compromise crew or vehicle safety, thereby demanding 
immediate action. In less urgent circumstances, they assumed an ad- 
visory role, describing the previously agreed-upon action to be followed 
after the anomaly's criticality had been determined (see Malfunction 
Procedures, item 8 below). 

6. Experiment Operations Handbook . The EOH was published in 
two volumes. Volume I was system oriented and provided experiment 
descriptions. Volume II contained detailed normal, backup, and mal- 
function operational procedures for these experiments. As such, this 
document provided the preliminary input for crew training purposes and, 
with feedback from training, formed the basis for the crew checklists. 

7. Crew Checklists . The crew experiment checklists were 
detailed, step-by-step procedures to be followed for proper experiment 
operation, included in the onboard Flight Data File. The MRD, experi- 
ment OM&H, acceptance and integration test results, EOH, and crew 
training experience were the principal inputs for these documents. 

They were updated as required during the mission by the ground support 
crew at the Mission Operations Center (e.g., to provide specific co- 
ordinates of an experiment target). 

8. Malfunction Procedures . The nature of space flight experi- 
mentation demands that experiment hardware possess a high reliability. 
During the development stage, every effort was made to ensure that the 
possibility of an in-flight hardware malfunction was negligible. De- 
spite this, experience has shown that failures will occur. A major 
advantage of manned space flight is the crewman's ability to repair 
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NOMENCLATURE 


PART NUMBER 



O-OPERATIONAL 

K-EXPERIMENTAL 

BLANK-MIXED 


SKY LAB PROGRAM 

SL-1 SL — 1/2 SL-1/3 SL— 1/4 

OPERATIONAL AND EXPERIMENTAL GFE/CFE STOWAGE LIST 


01 99 . 00«00|6-OS AUTOMATIC TIMER 


JsEBl 234-11 


s-stowed / 

W-VORH / 

M-MIXED / 

fclASA ORGANIZATION 
OR CONTRACTOR 
SUPPLYING TBE ITEM 
(SEE APPENDIX B) 


LAUNCH ASSEMBLY/ 
SUBASSEMBLY STOWAGE 
PROVISION INDICATOR 
(SEE NOTE I, NEXT PAGE) 


UNIT 

SPEC 

WEIGHT 

(LB1 


UNIT 
E ST/ ACT 
WEIGHT/COOE 
I LB) 


STORAGE LOCATION 


(DIMENSIONS- INCHES) 


2.100 2.085/A 

{1 .00X1 .05X0.50) 


D ITEM 
SPECIFICATION 
WEIGHT COMPARED 
TO LATEST ACTUAL 
OR ESTIMATED WEIGHT 
(/A OR /E) AND 
DIMENSIONS PER 
LATEST AVAILABLE DATA 
(SEE NOTES 2 AND 3 ON 
NEXT PAGE FOR 
GROUNDRULES) 



REFER TO 
NOTES SECTION 



5 5 

8 Ml 08 


L 1/3 AND 1/4; NO ADDITIONAL ITEMS ARE 
AUNCHED , BUT THE ITEM STOWED IN THE WS 
OCKER D426 IS TRANSFERRED TO THE MDA 
OCKER M108 DURING THE ORBITAL PHASE OF 
/3, AND REMAINS IN THAT LOCATION FOR 
HE DURATION OF THE PROGRAM . 


r, A 1 A1 A1 


SL 1/2 LAUNCH CONFIGURATION ; 

! ONE ITEM LAUNCHED IN THE VS 
! IN SUBCONTAINER A1 WITHIN 
LOCKER D426 , FIVE LAUNCHED IN 
CM LOCKER B8 t AND THREE ARE 
! WORN IN THE CM. 


SL 1/2 RETURN CONFIGURATION; FOUR ITEMS 
ARE LEFT IN ORBIT IN THE MDA LOCKER 
M108, AND ONE ITEM REMAINS IN THE WS 
LOCKER D426 • THREE ITEMS ARB RETURNED 
WORN IN THE CM, AMD ONE ITEM IS STOWED 
IB LOCKER B3. 


51 1/2 ORBITAL CONFIGURATION; 

ALL EIGHT ITEMS ARE TRANSFERRED 
OUT OF THE CM, FOUR INTO THE MDA 
WHERE ONE IS STOWED IN LOCKER 
MI08 AND THREE ARE PUT INTO USE, 

AND FOUR INTO THE WS WHERE THREE 
ARE WORM AND ONE IS CLIPPED TO 
THE FILM VAULT PER THE NOTE-USED 
IN LIEU OF A LOCKER LOCATION. THE 
ONE ITEM LAUNCHED IN SUBCONTAINER 
AI WITHIN D426 REMAINS IN THE LOCKER. 


011 CLIPPED TO SIDE OF FILM VAULT 0URIN6 MISSION 1/2 ACTIVE ORBITAL PHASE 


FIGURE A-5. STOWAGE LIST FORMAT (SAMPLE) 

















or work around many failures. The Malfunction Procedures, included in 
the onboard Flight Data File, provided the crew with logical steps to 
be followed when anomalies occurred. These procedures, expressed in 
block diagram format, were designed to rapidly isolate the anomaly to 
the subsystem or component which had failed and, where possible and 
applicable, described a repair method or alternate procedure which 
would permit continued operation. In the event that the malfunction 
procedure did not result in a satisfactory repair, the applicable mis- 
sion rule was invoked. 

9. Operational Data Book . During the mission, there may be 
occasions when the limit of certain design tolerances may be approached 
or exceeded, necessitating appropriate action. The ODB was a compila- 
tion of the operational performance data and limitations of all vehicle 
and experiment hardware. From the experimenter it required a descrip- 
tion of the mass properties, structure and dynamics of the equipment, 
the effect of experiment operation on the spacecraft environment, the 
nature of the load it presented to the electrical power system, data 
instrumentation requirements, experiment pointing capabilities and all 
operational limitations and hardware constraints. 

10. Sky lab Experiment Systems Handbook . The SESH was a com- 
pilation of experiment functional flow diagrams and, where applicable, 
mechanical and electrical schematics, for use by the flight controllers 
during the missions. It was designed to assist in the rapid resolu- 
tion of real-time experiment anomalies. Pertinent operational and 
system constraints were identified, as were the interfaces between 
experiments, where applicable. 

11. Facility Users Handbook . As part of an Announcement of 
Flight Opportunity, advising the scientific community of the availa- 
bility of an experiment facility (o.g., EREP) , a Facility Users Hand- 
book was prepared by the Experiment Development Center for distribu- 
tion to potential users. The handbook identified the physical/func- 
tional characteristics and operational capabilities of the facility 
and its individual instruments. 
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COMPATIBILITY ASSESSMENT 


A major feature of Skylab experiment integration activities was 
the continuing compatibility assessment performed by the Integration 
Center. This activity assumed various forms as the program developed. 

During the program’s formative stages, when many different 
missions and configurations were being considered, an extensive assess- 
ment was conducted to categorize over five hundred available or potential 
experiments into compatible, discipline-oriented payload groupings for 
performance on particular types of missions. While the early concept 
of numerous dedicated missions did not survive, these assessments were 
influential in selecting the initial experiment complement for the con- 
figuration and missions that were implemented. 

Subsequently, as new experiments were proposed for MSFEB con- 
sideration, an initial compatibility assessment was necessary in each 
case, to evaluate the impacts of the experiment requirements upon all 
other hardware and operational aspects of the program. Any incompati- 
bilities identified were resolved before the experiment was approved 
for imp lement at ion . 

Thereafter, a continuing surveillance was maintained of all per- 
tinent program documentation, information and activities to assure that 
the experiment requirements and constraints remained compatible with 
all interfacing cluster and module systems and operational plans. 

Where incompatibilities were identified, the Integration Center coor- 
dinated and participated in their resolution. All involved agencies 
(PI, ED, EDC, Module Developer /Development Center, operations centers, 
etc,, as applicable) were consulted and mutually acceptable solutions 
established. Normally, the Integration Center prepared and "precoor- 
dinaLed" any necessary change package for submittal to the cognizant 
CCB (bcg Section IX) and maintained corrective action implementation 
status. When significant hardware changes were involved, the affected 
hardware developer was responsible for preparation of the ECP, 

Many special studies were also conducted to assess the compati- 
bility of associated groups of experiments with their common module 
interfaces. Some examples were: multi-experiment usage of the Scien- 

tific Airlocks, module provisions for storage and environmental pro- 
tection of assorted experiment photographic film, launch pad access 
requirements for experiments, etc. 
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The various compatibility assessment activities continued at a 
high level throughout the definition, development, and integration 
phases, and as a monitoring and evaluation function during the mission 
support phase. Table B-I identifies and defines the general scope of 
the 17 experiment compatibility disciplines that were initially checked 
and subsequently monitored for these assessments. Figure B-l presents 
a matrix of the pertinent program documentation that was continually 
reviewed in the various discipline areas. 

Management visibility of the experiment compatibility status 
was provided by oral presentation of bimonthly reviews, and by broad 
dissemination of a monthly Experiment Compatibility Status Report. 
Representatives of the module development, launch, and mission opera- 
tions centers attended the bimonthly reviews and received the status 
report. A key feature of the monthly report was a compatibility summary 
of the status of each individual experiment relative to each of the 17 
compatibility disciplines (see figure B-2). The summary was supplemented 
in the report by detailed descriptions of current problem areas and their 
resolution status, including action items and suspense dates where 
applicable (see figure B-3). Once entered, problems could be closed 
and deleted from the status report only by issuance of a CCBD correct- 
ing the incompatibility, or by some equivalent positive action accept- 
able to the Integration Center. 

The evolution of these integration techniques provided a very 
effective means for the timely control of Skylab experiment compati- 
bility. 
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TABLE. B-I EXPERIMENT COMPATIBILITY DISCIPLINES 


DISCIPLINE 

DEFINITION 

Mechanical 

Verification that experiment mechanical interface re- 
quirements are met for mounting, alignment, orienta- 
tion, plumbing, venting, sealing, and the use of 
observation windows . 

Weight and 
Stowage 

Verification of current experiment weights relative 
to experiment and module control weights; of experi- 
ment stowage provisions in terms of weight, volume, 
and location for each launch, orbital storage and 
return operation in the mission; and that all onboard 
experiment support equipment is available at the time 
and in the quantities required. 

Consumables 

Verification that experiment requirements for oxygen, 
nitrogen, water, and/or other consumables will be 
supplied either by the modules or by the experiments 
themselves . 

Electrical 

Verification that experiments are compatible with 
the electrical power provided by the module (voltage 
tolerances, power profile, and total energy); that 
all electrical interfaces are compatible (connectors, 
cables, etc.); and that EMI produced in the electri- 
cal system will not cause unacceptable degradation 
of the system or experiments. 

Ina trumenta tion 
and 

Communications 

Verification that experiment measurements, house- 
keeping measurements, voice communication, and ground 
commands required for the experiments will be provided; 
that experiment equipment, data formats, and data rates 
will be compatible with module requirements for record- 
ing and transmission to ground, and with MMC require- 
ments for processing and display; that all data 
correlation requirements (e.g., time, ephemeris, etc.) 
will be provided for; and that experiment -required 
data will not be lost due to EMI. 

Environments 

Verification of experiment compatibility with prelaunch, 
launch, orbital and recovery environments (temperature, 
humidity, pressure, acoustic, vibration, acceleration, 
shock, radiation, illumination) as specified in the 
CRS or defined by NASA-recognized analyses; and of crew 
and system compatibility with experiment -induced en- 
vironments. 

Materials 

Verification that experiment materials are acceptable 
in accordance with the appropriate specifications as 
referenced in the CRS, or that waivers to these spec- 
ifications have been approved. 
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TABLE B-I EXPERIMENT COMPATIBILITY DISCIPLINES (Cont.) 


DISCIPLINE 


DEFINITION 


Contamination 

Evaluation of experiment susceptibility to contamina- 
tion from internal or external sources; determination 
of contamination produced by the experiments; and 
verification of ground contamination control procedures# 

Photography 

Verification that experiment photographic requirements 
are met, including photographic support equipment 
(cameras, lenses, light, cables, etc.) and film; and 
that adequate environmental protection is provided 
for film. 

Experiment 
and Spacecraft 
Pointing 

Verification that experiment pointing requirements 
will be met when integrated into the spacecraft; and 
that requirements imposed on the spacecraft, including 
orbit position for performance, orientation, stability, 
allowable rates and accelerations, and the necessary 
maneuvers, will be provided for* 

Safety 

Verification of experiment safety plans and provisions 
for on-orbit operations. 

Systems Test 

Verification of compatibility of all experiment handling, 
test and checkout plans with integration test planning, 
pre launch maintenance, logistics, pad access, and launch 
constraints . 

Ground Support 
Equipment, Facil- 
ities and Handling 

Verification that GSE and facilities provided will 
satisfy the experiment postacceptance handling and 
testing requirements with minimum duplication. 

Flight 

Plans 

Verification of flight plan compatibility with experi- 
ment requirements, priorities, objectives, constraints, 
and interfaces . 

Crew 

Interfaces 

Verification of experiment-to-crew Interfaces, includ- 
ing in-flight access, restraints and aids, controls and 
displays, in-flight maintenance, and crew training. 

Mission 

Support 

Verification of plans for obtaining required evalua- , 

tion data; for processing, display, analysis, and 
reporting of this data in support of the mission; 
and for analysis and reporting after, the mission. 

Schedules and 
Hardware Status 

Verification and. comparison' of required dates and 
delivery dates for experiment mock-ups, trainers, 
flight hardware (including backup unit), and GSE. 


85 




Ainvnt) sood &o 

gi af)Vd T VNIOIdO 


98 



Documentation Used in Compatibility Assessment 
As of December 1, 1572 






ORIGINAL PAGE IS 
OF POOR QUALITY 


fceperiment Compatibility Matrix; 
As of December 1, 1972 


EXPEAIKOfT 


OPEBATIORS 


TECHNOLOGY 


EARTH RESOURCES 


DISCIPLINE 


MECHANICAL 


HEIGHT AND STOWAGE 


CCBSUJMLES 


9v n cn 
Q — ' 

£ £ £ 


O'! ^ - 


* * « « 

r» oo 

WV fH 

£222 


c o ci c 


IMBHBBBBBBHBBBBBBBBBBBBBBBBHBBBHHHBHHHHW*mnHHS 


IRSTROMEHTATTOW & Ct»*flKICATIOS 


OnriEOKMENTTS 


CtirTAMlNATIOW 


PHOTOGRAPHY 


mBW/MBBWBmBEEE 


BE%EB 


EXPERIMENT A CLUSTER POIFTTHC 


SYSTEM TEST 

CSE FACILITIES AMD HAMDLIBG 


IBggHBBBBBBHBBBHBgBBiBBEiiBBBEEBEBEBBBBEBBBBBEEl 
55S55sSI55S5s5555IS5SSSSSSSEIEiilSiiEMHHHH 
IBBHB BBHBBHHH HHBHHilBilHHH miBBBBWBEIlBliWBBWWHHPIlii 

IBBBBB3BHBBBBBBBBBBBBBBBBBBHBBBBimmiHBHH»!HKHHHHri 


m 


§§§§5S§§§@BBBBBBBBEBBBEBBBBBBBEBBBEEEEEE:MBBBBE 

!BBBBBBBBBBBBBBBBB BBEBEEBEB EEBBE B ErBWHHHWwB«««in" 

IBBBHBBBBBBHBHHBHBBHHBHBHHEEHBEEWEEWWW»jEw»MjBwaHfe 


Problem verified by MSEC 

Potential problem identified 

Open* Inadequate Loformtion available or 

aiKiiBeot la progreu 


Experiment compatibility established 
■o compatibility requhimant 

Indicates EXD not yet baselined by MSEC or none 
available. 


FIGURE B-2. EXPERIMENT COMPATIBILITY SUMMARY (SAMPLE) 


























Experiment Compatibility Problem Areas (Contd) 




ACTION ASSIGN- 

C0MPLE- 


PROBLEM 

EXPERI- 

RES PONS I- MENT 

TION 


NUMBER 

MENT(S) 

INCOMPATIBILITY BILITY DATE 

DATE 

CURRENT STATUS 

24 

S019 

This experiment uses 


The S019 PI has decided 



triacetate base film. 


to use film type 101-06. 



ESTAR base film is 


This change was approved 



less flammable. 


by CCBDs 800-72-0586, 



exhibits much better 


10-9-72, and 2X0223, 



physical character- 


8-11-72. 



is tics (especially 
with regard to out- 
gassing) , and is 
available in 
thinner bases. 


PROBLEM CLOSED. 

*25 

T027/ 

The Photometer Tri- SL-SW 10-11-72 

TBD 

Phase I DCR RID T027P-4 


S073 

pod has not been 


recommended Qual Test to 


SI49 

qualified to launch 


launch vibration levels 


PCTVS 

vibration levels and 


and 100 setup/ takedown 



has not been cycle 


cycles. The recommended 



tested. In addition. 


RID action has not been 



several expando pins 


taken. In lieu of the 



and one floor insert 


above testing. Memo S&E- 



were broken during 


ASTN-DIR(72-385), 10-11- 



operational tests 


72, requests a repair (or 



at MDAC-W. 


spare) kit to provide for 
continued use of the tri- 
pod in the event of damage 
to expando pins, bolt 
assemblies or floor in- 





serts. ECfa in preparation 
by S&E-ASTN-SMD and -SDI 





to add the spares. 

1 * Problem newly added in this issue of report. 
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DEVELOPMENT REVIEWS AND CERTIFICATION 


This Appendix describes the requirements, responsibilities and 
methodology for accomplishment of the formal reviews and certifications 
which were key development checkpoints for Skylab experiments. The 
seven key management checkpoints established by Skylab Program Directive 
No. 11 were: 

PRR - Preliminary Requirements Review 

PDR - Preliminary Design Review 

CDR - Critical Design Review 

CIR - Configuration Inspection Review 

COFW - Certification of Flight Worthiness 

DCR - Design Certification Review 

FRR - Flight Readiness Review 

The Experiment Development Center was responsible for accomplishment of 
the first five of these (PRR, PDR, CDR, CIR and COFW) at selected end 
item levels. The last two reviews (DCR and FRR) were program-oriented, 
encompassing the total mission complex; they were accomplished through 
coordinated efforts of the development, integration, launch, and mission 
operations centers, and were conducted in a different format by the NASA 
Headquarters Program Director. Experiment involvement in the DCR and 
FRR is described in Section VI of the main text. 

Each development review was a critical examination of documentation 
and pertinent hardware for compliance with program requirements and for 
compatibility with related hardware and facilities. The reviews progressed 
chronologically from requirements (PRR), to design (PDR, CDR), to hardware 
acceptance (CIR) and formal certification (COFW). Each successive check- 
point provided a more comprehensive assessment of program accomplishment 
as it matured. 


A. Purpose and Scope of Reviews 

1. Preliminary Requirements Review . The purpose of a PRR was 
to verify by formal review the suitability of the conceptual configuration, 
and to establish a Program Requirements Baseline that would satisfy the 
experiment objectives and provide the basis for preliminary design. Review 
material included the experiment proposal, the approved EIP, the Compati- 
bility Assessment, the ED's Statement of Work (SOW), and initial versions 
of the ERD and EIS, The PRR established: 

o A preliminary EIS for the conceptual flight hardware configu- 
ration that would be expected to meet mission objectives and 
the required schedule. 



o Operational requirements of the experiment on the module, 
crew, launch, flight and recovery, as reflected in the 
preliminary ERD. 

o Required end items and schedule. 

o Feasibility and/or development tests required to select 
and substantiate design approaches. 

Minutes of the PRR were prepared, as described in Section A. 2.d of 
Appendix A, and included all items requiring post-review action. These 
action items were to be completed prior to final approval of the Program 
Requirements Baseline. 

2. Preliminary Design Review . The purpose of a PDR was to 
verify by formal review the basic design approach for the hardware, prior 
to proceeding with detail design, and thereby to establish a Design 
Requirements Baseline. The PDR established: 

o The integrity of the design approach, by review of design 
analyses, breadboard models, mock-ups, circuit logic 
diagrams, packaging techniques, test and study results, 
reliability analyses, etc. 

o The compatibility of the design approach with EIS perfor- 
mance and design requirements, including interface compati- 
bility with other flight hardware, the flight crew, GSE and 
facilities. This was accomplished by review of preliminary 
design drawings, layout drawings, envelope drawings, 
schematics, performance characteristics for functional 
compatibility, and available test results. 

o The producibility of the design approach with respect to 

cost and schedule impact, through the review of requirements 
for special tools, equipment, and facilities to manufacture, 
inspect and test the hardware. 

o The adequacy of the planned test program for the end item, 
by review of preliminary test plans. 

o The acceptability of the design requirement baseline con- 
figuration, through approval of the design approach. 

Minutes of the PDR were prepared and included all items requiring post- 
review action. These action items were to be completed prior to formal 
approval of the Design Requirements Baseline configuration. 
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3. Critical Design Review . The purpose of a CDR was to 
verify by formal technical review the completed detail design of the 
hardware, and to establish a production Drawing Baseline before the 
design was released for manufacture. The CDR established: 

o The integrity of the completed design, by review of 
the drawings (as prepared for release to manufactur- 
ing), analyses, mock-ups, qualification status of 
selected parts and materials, test data, inspecta- 
bility, etc. 

o Compatibility of the completed design with EIS per- 
formance and design requirements, as revised since 
PDR. This included the exact physical and functional 
interface relationships with other flight hardware, 
the flight crew, GSE and facilities. 

o The production baseline configuration for manufacture 
of the hardware, through approval of the completed 
design and associated documentation. 

o Adequacy of the planned test program, by baselining 
the Qualification and Acceptance Test Specifications. 

o Adequacy of the design from a safety standpoint, 

through a review of design details and test results, 

o Adequacy of the design for operations, by review of 
engineering simulations, tests and study results and 
by examination of mock-ups, operating procedures, and 
system performance data. 

Minutes of the CDR were prepared and included all items re- 
quiring post-review action. These action items were to be completed 
prior to formal approval of the baseline configuration for manufac- 
turing . 


Configuration Inspection Review . The purpose of a CIR 
was to verify by formal technical review that the configuration of 
the end item as being offered for delivery was in conformance with 
the baseline established at CDR (as modified by approved changes). 
This was accomplished by establishing the exact relationship of the 
end item as described by released engineering documentation to the 
end item as manufactured and assembled. The CIR was most efficiently 
conducted In two phases: 
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Phase 1 - Approximately one week prior to start of final 

experiment hardware acceptance tests, review the 
qualification status and test data, configuration 
and overall status of the end item and its GSE, 

Phase 2 - Approximately one week prior to delivery, review 

the final experiment hardware acceptance test- data. 

The CXR established: 

o That the hardware to be accepted conformed to the pro- 
duction baseline configuration, as documented by the 
released engineering, including all approved changes; 
and that the configuration of the Qualification Test 
hardware corresponded to the configuration of the 
flight hardware to be accepted. 

o That the test program of the Verification Plan had been 
completed and that the verification methods and test 
results validated the acceptability of the hardware. 

o That all failures occurring after CDR had been reported 
and corrective action completed. 


o That Failure Mode and Effects Analyses had been com- 
pleted and were acceptable. 

o That the Acceptance Data Package was complete and 
acceptable. 

o The validity of the hardware acceptance testing, 
verified by a direct comparison of acceptance test 
data with ElS performance and design requirements 
and by verification that the acceptance tests had 
been conducted in accordance with the approved 
Acceptance Test Specification and procedures. 

o A plan for accomplishing any open work items remain- 
ing for fulfillment of the above requirements. 

o Identification of all waivers, deviations or 
shortages authorized. 

The results of the CIR were documented in a CIR Report (see Appendix 
A, section A.2.e). 


5. Certification of Flight Worthiness . The purpose of the 
COFW milestone was to certify that each experiment end item was a com- 


plete and qualified item of hardware prior to shipment, and was accom 
panied by adequate supporting documentation. The COFW was prepared 
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prior to shipment from the point of manufacture and endorsed by the 
EDC • The COFW certified that: 

o Complete specifications and drawings had been developed 
in accordance with all program requirements* Addition- 
ally, that the exact relationship of the hardware as 
manufactured and assembled had been established, and 
that shortages requiring resolution prior to FRR had 
been indicated on the DD-250 form, 

o Acceptance, qualification, and any required reliability 
demonstration tests had been successfully completed and 
had met specification requirements. 

o Departures from specification and drawing requirements 
had been approved by Material Review Boards in accord- 
ance with £1S requirements, 

o Critical hardware failures had been reported, analyzed, 
and corrected in accordance with EIS requirements. 

o The hardware qualification program had been satisfac- 
torily accomplished. 

o The hardware was complete and in accordance with the EIS. 

o Data for operation and checkout was complete and com- 
patible. 

o Interface Control Document requirements had been met and 
interface compatibility was certified, 

o Shipping and transportability requirements as stated in 
the EIS had been met. 

o Delivery status information as required in the EIS was 
complete, 

o The DD-250 form was ready for signature. 

When equipment was shipped to an intermediate destination 
(center test facility or developer’s plant) for additional work, 
further sign-off of the COFW by the cognizant center was required. 
Eventually, upon completion of the FRR, the COFW was jointly endorsed 
by the Launch Center and the EDC. 
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B. Review-Format and Activities 

The review description and requirements contained in this 
section were generally applicable to all development reviews; however , 
flexibility was permitted to meet the requirements of each experiment 
review. For example, the formal procedure of using Review Item Dis- 
crepancy (RID) forms to document problem areas was- properly followed 
for major reviews (e.g., for modules or complex experiments), but was 
occasionally supplanted by a simple Action Item Log to accomplish the 
same purpose in reviews of the less complex experiment s . This flexi- 
bility was implemented by a Review Agenda prepared specifically for 
each experiment review by the cognizant EDC. 

Review personnel consisted of: 1) review teams or working 

groups, representing each appropriate technical discipline or program 
interest, to conduct the detailed technical review; 2) a preboard, to 
perform a screening and advisory function; and 3) the review board, to 
direct the proceedings and make final disposition of all pertinent re- 
view items. The board and preboard normally included representation 
from the EDC, NASA Headquarters, the Integration Center, the operations 
centers, the ED and the PI or Project Scientist. The designated cap- 
tains of the review teams also served on the preboard. 

1. Preparations . The cognizant EDC scheduled the review 
date(s) and site, and appointed the review board chairman, who in 
turn selected his preboard chairman and team captains. Approximately 
two months in advance, this group prepared the Review Agenda, notifying 
invited participants of review objectives and personnel, session 
timing, applicable documents to be made available, and planned devia- 
tions from normal review procedures, if any. At least two weeks prior 
to PRR, PDR, or CDR, the EDC or ED delivered to each participant a data 
package, consisting of updated plans, the appropriate technical documen 
tation, and RID forms. Participants were expected to familiarize them- 
selves with the documentation, and identify suspected discrepancies and 
problems, in advance preparation for the review. 

RECOMMENDATIONS: Apply the following criteria in prepara- 

tion for experiment development reviews. For maximum 

effectiveness, each review must: 

o Be conducted at the appropriate time--in particular, 
not prematurely with respect to data definition and 
availability. 

o Involve the most experienced technical personnel 
available to cover all disciplines that affect the 
reviev subject. 
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o Limit participants to the required discipline and 
project representatives, authorized to act for 
their respective organizations (including a single 
source of crew comments, consistent from one review 
to the next). 

o Have a data package that is complete, but minimal 

in volume, available to all participants sufficiently 
early to permit thorough evaluation. 

o Emphasize hardware as available. 

o Include assessment of test programs and results. 

2, Technical Review . Technical reviews began with a general 
technical briefing by the EDC/ED, to provide all review participants 
with common background information on development status and technical 
requirements and final instructions as to review procedures, criteria, 
and guidelines. 

Due to the relative complexity of the review materials, indi- 
vidual team sessions were scheduled for each applicable technical and 
management discipline. The team sessions opened with detailed presen- 
tations to assure maximum understanding of the technical materials 
subject to review in the team’s defined area of responsibility, as 
interpreted by the team captain. The remainder of the team sessions 
were devoted to in-depth examination and discussion of the review 
material, leading to the generation, review and coordination of RIDs, 
and development of recommendations for their disposition. The MSFC 
standard RID format is shown in figure C-l* The team members sub- 
mitted their discrepancies/problems to the team captain to assure 
proper format, completeness, clarity, coordination, and that the 
content was within scope of the review guidelines and criteria. After 
his review the team captain could recommend to the originator that 
the RID be withdrawn, rewritten or combined with another RID of the 
same intent. However, any action or changes to a RID during the team 
meeting and subsequent activities required the concurrence of the 
originator. RIDs approved for submittal into the review data flow 
were logged, submitted for the developer's response, and coordinated 
with other review teams as required. The developer's appointed lead 
representative for each team provided or made readily available the 
supporting documentation, analyses or explanations required to clarify 
or resolve questionable areas encountered during the review. He also 
coordinated preparation of the developer's response to submitted RIDs, 
provided liaison for coordinating the team's activities with other 
teams, and prepared team minutes. 
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1. TYPE OF REVIEW 


2, ITEM 


3. DATE: 


6. INITIATOR; 


10, title; 




REVIEW ITEM 

discrepancy 

7. organization: 

a. system: 



0. TEAM NAMES 



13. RECOMMENOEO DISPOSITION: 


14. TEAM CAPTAIN'S SIGNATURE: 



17.2 CATEGORY: 


17.3 ACTION: 


17.4 SUSPENSE : 


IB. 4 SUSPENSE: 


17, PRE-BOARD RECOMMENDATIONS 


17.1 REMARKS 




IB, FORMAL REVIEW BOARD ACTION 


IB. 1 DISAPPROVED 

IB. 2 REMARKS: 


18.5 □ APPROVED 


20. SIGNATURE OF BOARD CHAIRMAN 


MSEC • rorm jjn {May 1969) 



FIGURE C-l. MSEC RID FORMAT 
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3. Preboard Action . The preboard convened, before the board 
meeting, to screen and categorize all RIDs submitted by the review 
teams. Each RID was considered individually by the preboard, combined 
with others where possible, and assigned to one of the following recom- 
mended disposition categories: 

A. Recommend acceptance as written 

B. Recommend acceptance with (stated) modifications 

C. Recommend acceptance for study 

D. Recommend rejection 

E. Refer to board for resolution 


The total R.1D package, accompanied by pertinent data to support the 
recommendations, was then submitted to the review board for final 
disposition. 

4. Review Board Action . The board reviewed the RID package 
and, after considering the preboard's recommendations, either approved 
or disapproved each presented RID. Suspense dates were established 
for all items requiring further action. (As noted previously, the 
formal RID procedure was replaced in some reviews by a simple Action 
Item Log.) The official review minutes (or CIR Report) provided the 
formal documentation of the board's actions and directions. 


5. Follow-Up Action . The EDC was responsible for assuring 
satisfactory review follow-up, i.e., that approved RIDs were imple- 
mented, directed studies completed, and appropriate action taken to 
close all remaining open items by the prescribed suspense dates. 

Upon completion of all required follow-up activity, the final review 
minutes were prepared and distributed by the EDC, documenting the 
closeout actions and dates, and certifying to the Program Director 
that the review objectives had been met. 


RECOMMENDATION: Emphasize the importance 
follow-up and formal closeout of all RIDs 
action items, and timely dissemination of 
mation to all involved program personnel. 


of adequate 
or review 
this infor- 
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DESIGN CONSIDERATIONS 


The following experiment design considerations are categorized into 
those applicable to flight hardware and those applicable to GSE. These 
considerations were usually specified as requirements in either the CRS 
or the experiment EIS. Some considerations were only indirectly applic- 
able to design (i.e,, identifying operational methods or procedures that 
might influence the design). The importance of applying these design 
criteria was directly related to the criticality category of the experi- 
ment, i.e. : 


Category 1: Hardware whose failure could adversely 

affect personnel safety. 

Category 2: Hardware whose failure could result in not 

achieving a primary mission objective, but 
would not adversely affect personnel safety. 


Category 3: Hardware whose failure could result in not 

achieving a secondary mission objective, but 
which would not adversely affect personnel 
safety or preclude the achievement of any 
primary mission objective. 

Category 4: Hardware whose failure would not result 

in any of the above. 


A, Flight Hardware 

1. Flight Operation general Constraints 

a. Safety of the crew and safe termination of the mission 
were overriding design criteria. 

b. All components that controlled safety-critical functions 
were required to be designed to operate in a vacuum. This was consid- 
ered a requirement even for hardware normally located in a pressurized 
environment . 

c. Efforts were made to minimize the number of single fail- 
ure points (SFPs) in the design; rationale to justify acceptance of 
those SFPs that did exist was a prime consideration in design and 
acceptance reviews. Redundant systems, however, were to be provided 
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only if considered necessary to ensure crew safety or primary mission 
success* 


d. Wherever possible, opportunities for human error were 
minimized by designing connecting parts (e.g, a fluid line or electrical 
connectors that might be reversed in mating) so that they would be 
physically incapable of being installed improperly. 

e. The experiment was designed to satisfy its own objectives, 
independent of the failure of another experiment. 

f. Wherever feasible, flight-proven hardware was utilized in 

the design. 

g. The module generally provided the following subsystems: 

1) Data Recording, 2) Power Distribution, 3) Pressurization, 4) Attitude 
Control, 5) Voice Communications , 6) Atmospheric Circulation, 7) Module 
Lighting, Food, Water and Waste Management, and 8) Central Caution and 
Warning System. 

2. Flight Operation Mechanical Constraints 

a. All experiment hardware having a crew interface was re- 
quired to remain within touch temperature limits of 55 F to 105 F. 

b. The following types of hardware were required to be 
delivered to the Module Development Center: 

(1) Mechanical interfaces tool (a tool that could be 
used to verify mechanical interfaces prior to installation; e.g., to 
locate bolt holes). 

(2) One full-scale mock-up of the experiment that, as 
a minimum, satisfied mechanical and crew interfaces. 

(3) One flight unit. 

(4) One complete set of GSE capable of verifying inter- 
faces and checking out the experiment to acceptance test requirements. 

c. Packaging. Experiment equipment which was stowed during 
the launch phase of the mission, and then transferred to a use location, 
was required to satisfy the following specifications: 

(1) Package limited in size to 20" x 25 n x 40" and in 
moment of inertia to less than 65 lb-in-sec , and allowing adequate 
visibility during transfer. [NOTE: Skylab mission experience indi- 

cated no difficulty in handling large masses in zero g; however, the 
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cross-sectional area of 20" x 25" was considered a realistic limit from 
the visibility standpoint, J 

(2) Hinges designed so that all hinged devices remain 
as positioned by the crewman. 

(3) Rounded edges and corners of packages and containers. 

(4) Package fasteners able to withstand prelaunch, 
launch, and flight loads and: 

(a) Designed to prevent inadvertent operation. 

(b) Simply operable with either a bare or a pres- 
surized-gloved hand, without requiring extensive astronaut stability 
aids. Sky lab crews indicated a preference for magnetic or lift-handle 
latches . 

(5) Each package marked to indicate: 

(a) Proper mounting orientation. 

(b) Equipment-peculiar precautions. 

(c) Operating instructions, where feasible. 

(6) Cameras/film canisters, and other equipment trans- 
ferred during EVA, designed to meet the following requirements: 

(a) Capability for one-hand operation. 

(b) Capability for tethering. 

(c) Mounting provisions compatible with equipment 

transfer devices. 

(7) Package mounting provisions designed to avoid pro- 
viding a space for floating articles to pass behind and/or accumulate. 

3* Flight Operation Electrical Constraints 

_ ,, a * Module power provided to experiment interfaces had the 

following characteristics: 

(1) Two-Wire System. Power was distributed by a two- 
wire system. The system did not use module structure for return of 
current to the power source. 


102 



(2) Grounding. Any one set of negative buses was 
referenced to the structure at only one point. The experiment could 
not use module structure for return of current to the power source. 
The module provided the single-point ground. 

(3) Bonding. Electrical bonding and grounding of the 
experiment was in accordance with MIL-B-5087 , providing a radio fre- 
quency ground reference plane, a fault current return path, and a 
discharge path for lightning and static charge. 

(4) Circuit Protection. All experiment positive 
polarity lines of the DC distribution wiring were protected with 
circuit breakers or fuses provided by the module. Use of fuses was 
minimized. 


(5) Crew Mating or Demating of Connectors On-Orbit, 
The presence of power in the connectors during mating or demating by 
the crew was circumvented by design or procedure. Connector design 
or application precluded mismating. 

(6) Characteristics of Unregulated 28 V DC Power at 
Interfaces. 'The voltages at module interfaces met the following re- 
quirements : 

(a) Bus Noise. The total AC components of the 
voltage could not exceed 1.0 volts peak-to-peak for all frequencies 
from 20 Hz to 20 KHz. 

(b) Under and Over Voltage. Under and over 
voltage with a duration greater than 10 microseconds and less than 
100 milliseconds could not exceed the limits 28 + 4 by more than 3 
volts. 


(c) Transients. Transient voltage with a dura- 
tion of less than 10 microseconds could not exceed + 50 volts relative 
to the limits 28+4. 

b. The module provided interface cabling: 1) between 

sensor and control panels, and 2) between experiment hardware com- 
ponents if the cabling required mechanical support from the module. 

c. Experiment electrical design considerations were: 

(1) The experiment provided a rapid means of switch- 
ing off power under emergency conditions. 

(2) The experiment control panel provided a positive 
indication of power-on, current level, and power-off status. 
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(3) Experiment safety-critical and nonsafety-critical 
circuitry were isolated from each other, 

(4) Secondary power sources were provided for experiment 
safety-critical functions. 

(5) Experiment safety-critical electrical components 
were protected against the effects of liquid leakage, moisture, con- 
densation, vibration, arcing contacts and corona. 

(6) Experiment electrical disconnects were located 
separately from hazardous fluid disconnects, were qualified as ex- 
plosion-proof and would not have power applied to the connection 
during or after disconnect. 

(7) If batteries were used, they were designed to 
prevent danger of explosion under any conditions. 

(8) Cabling was placed so that it could not be sub- 
jected to loads for which it was not designed (e.g., use as a hand- 
or foot-hold), 

(9) Use of high-voltage systems was minimized. 

d. The design of an experiment was required to satisfy 

EMI criteria that met the following minimum requirements: the oper- 

ation of the experiment in any mode (powered or unpowered) could not 
degrade the performance of another subsystem relative to that sub- 
system's performance criteria. The hardware would satisfy the single- 
point ground requirement and meet EMI MIL-STD-461. Verification of 
this was required during the qualification/development phase, and 
evidence of meeting these criteria was included in the ADP. 

e. Pyrotechnics 

(1) Use of pyrotechnics by experiments was minimized 
and required approval by NASA. 

(2) Pyrotechnic initiators could not be susceptible 
to ignition In the EMI environment of the module. 

(3) The arming of pyrotechnic devices was protected 
against accidental operation. Arming and safety were clearly indicated. 

(4) Pyrotechnic exhaust products were contained or 
controlled to prevent ignition of combustibles. 



(5) The pyrotechnic logic circuits received power 
from a source other than the pyrotechnic initiation batteries. 

(6) Pyrotechnic devices required for safety were 
designed to allow verification. 

(7) Pyrotechnic firing circuits were protected from 
electrostatic charge buildup. 

(8) Sequence logic and pyrotechnic firing circuits were 
required to be at least "fail-safe/fail-safe". 

4. Flight Operation Controls and Displays Constraints 

a. Circuit Protection. Circuit breaker devices had manual 
reset capability and a visual display of position. 

b. Panel Lighting. Console floodlighting, electrolumi- 
nescent panel lighting, and numeric displays were controllable in 
intensity steps at the panel or console. Lamp testing capability was 
provided for panel displays. Radiation or luminescent type paint was 
not allowed. 


c. Emergency Lighting. The module provided the manual 
or automatic emergency lighting of the work areas. This requirement 
could be satisfied through the use of overhead emergency lighting. 

d. Automatic/Manual Override. Controls and displays pro- 
vided the capability for manual override of critical automatic systems 
to assure mission success or crew safety. 

e. Ground/Crew Operations. Experiment displays for ground 

and crew controlled systems reflected true system status. [NOTE: Some 

problems were encountered during the missions with inaccurate or un- 
reliable film and magnetic tape usage indicators.] 

f. Pyrotechnics Control. The flight crew was the sole source 
of control of all pyrotechnic devices required for on-orbit operations. 

g. Redundancy Control. Crew controls were provided for 
selection of redundant system capabilities. 

h. All controls and displays were recessed or provided with 
"bump-proof" switch guards, especially for panels located in high-traffic 
areas . 


i. Operation of experiment controls was limited to one-man 
operation, i.e., no single experiment operation required two crewmen 
simultaneously. 
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j. The crew monitored the progress of each experiment 
observation and were provided the capability to terminate observation 
due to lack of data quality. 

k. Instruments provided automatic calibration, but pro- 
vided crew capability to initiate a calibration procedure. 

l. Where feasible (and not excessively time-consuming), 
crew capability to perform a function effectively was utilized instead 
of automating the function. 

m. Experiments were designed to operate in a powered-down 
mode during launch and reentry phases. If any experiment operation 
was required during these phases, it was monitored and controlled from 
the module. 


5 « Flight Operation Crew Interface Constraints 

a. To the maximum extent possible, crew mobility/stability 
aids for experiments were preinstalled. 

b. The crewmen were alerted to any existing or impending 
crew hazard condition by an appropriate signal to the Caution and Warn- 
ing System. 


c. Attachment provisions for mounting the carry-in equip- 
ment, instruments and devices, if any, were preinstalled in the module 
prior to launch. 

d. All launch-stowed experiment equipment was stowed such 
that it could be obtained without EVA. 

e. The module generally provided the following crew aids 
and restraints: 


(1) Provisions for locomotion and restraint were 
located throughout the module to facilitate crew movement between 
various work stations. 

(2) Both permanent and portable general restraint 
devices were provided, to allow the crew to adequately perform acti- 
vities at the various crew stations. 

(3) Adequate foot restraints were provided each crew- 
man for use while performing normal or contingency tasks. 

f. EVA tasks, including contingencies, could not require 
more than two crewmen (i.e., at least one crewman remaining inside the 
spacecraft at all times). 
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g. A manual backup mode was provided for all mechanical, 
EVA, and film magazine transfer devices. 

h. EVA crew work stations at the experiment were illumi- 
nated to 5 ft-lamberts minimum. 

i. The module provided the capability to turn off all 
external lights, either by crew or ground command, while performing 
light-sensitive experiments. 

j. Human Engineering. MSFC-STD-267 or MIL-STD-1472 were 
applied as guides for standards and practices for Human Engineering 
design. 

6 . Other Flight Operation Constraints 

a. Fire, Toxicity, Radiation. 

(1) Nonflammable structural materials were required 
in the module environment. Interior walls and secondary structure 
were constructed of self-extinguishing material. 

(2) To the extent necessary to ensure crew safety, 
materials selected for use in habitable areas were nonexplosive, non- 
flammable, nontoxic, and low- out gas sing under normal operational con- 
ditions as well as under conditions of depressurization. 

(3) Experiment radiation sources required NASA EDC 
approval for usage. 

b. Contamination Control 


(1) Shields 

(a) Contamination -sensitive elements were located 
to take maximum advantage of natural shielding by the vehicle structure. 

(b) Contamination-sensitive elements were shielded 
from any direct impingement of the attitude control system or venting 
contaminants, unless such shielding would be detrimental to the opera- 
tion of the contamination-sensitive element. 

(2) Covers . 

(a) All optical instruments exposed to the external 
environment were protected from contamination during non -data -taking 
periods by movable covers over the instrument aperture. 

(b) Instrument covers were designed so that the 
most probable failure modes were in the open position. A backup 
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activation mechanism to permit emergency cover opening was provided. 

(c) Storage containers were provided for contami- 
nant-sensitive experiments which were stowed in the module. Containers 
were atmosphere- tight and capable of dry nitrogen purge or evacuation 
after insertion of the experiment for storage. 

(3) Material Selection, All materials used in con- 
struction of experiment and module hardware were evaluated for out- 
gassing and dusting characteristics. The following specifications 
were applicable: 


(a) Material Outgassing Control. Materials se- 
lection conformed to the requirements of the program specifications 
(e.g., 50M02442, ATM Material Control for Contamination Due to Out- 
gassing) . 


(b) Material Dusting Control. All materials were 
selected for minimum dusting, powdering, or flaking characteristics. 
Where no acceptable material to perform the function was available, 
covers or coatings were used to contain the dusting products, or other 
protective means (such as filters) were provided for reduction of dust 
products entering the cabin or external atmosphere. 

(4) Wherever practical, mirrors, lenses, prisms, 
windows and other instrument optical elements that were expected to 
be degraded by contamination were designed so that they could be 
periodically replaced by the crew with a spare element. 

(5) Electric heaters on windows, lenses and mirrors 
were used where practical to maintain the optical element at an ele- 
vated temperature in order to prevent contaminant deposition, or to 
periodically heat the optical element (window) to drive off accumu- 
lated internal condensation. 

(6) Photographic film was packaged in canisters to 
reduce possible contamination effects prior to camera loading. Pre- 
mission film testing revealed that certain film types (in particular, 
Schulman types, non-overcoated) are susceptible to severe fogging in 
the presence of non-anodized aluminum or copper; these materials should 
be avoided in design of film storage containers. 

(7) Venting and Dumping. 

(a) Waste storage tanks were of adequate size 
to allow a minimum of one orbit's accumulation between dumps. (The 
design goal to store all liquid wastes for the entire operational 
period was actually achieved.) 
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(b) Waste vents were positioned as remotely as 
possible from sensitive surfaces and were directed so that minimum 
impingement occurred on any module components, 

(c) Nozzle orifice design and discharge pressure 
were chosen to provide the minimum practical cone angle pattern for 
the discharge stream. Waste dribble at the beginning and end of a 
dump was minimized. 


(d) Solid waste was packaged and stored wherever 
possible. If dumping was required, all solid waste was dumped into 
the waste tank in packaged form. Dumps were timed to occur between 
operations of critical experiments, 

(8) To avoid contamination, dry lubrication was the 
preferred method for mechanisms exposed to space. 

7, Ground Operation Constraints for Flight Hardware , 
a. General Constraints 


(1) Experiments were installed in the module prior to 
installation of the module on the launch vehicle. 

(2) All subsystems included provisions for deactiva- 
tion and monitoring required to assure personnel and hardware safety, 

(3) The experiments were designed to allow integration, 
checkout, operation, refurbishment and maintenance activities to be 
performed in either horizontal or vertical position, 

(4) All hardware was capable of satisfying and main- 
taining Class 100,000 cleanliness as a minimum, 

b. Mechanical Constraints 


(1) Interface cables and fluid lines were of suffi- 
cient length (service loop) to allow interface connections to be made 
before mechanical mating of the experiment 

(2) Interface fluid lines and electrical cables were 
designed so that individual cables or lines could be removed without 
disrupting the integrity of adjacent lines, 

(3) Transportation and handling equipment was designed 
to ensure that flight structures were not subjected to transportation 
loads more severe than flight design conditions. 
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(4) Design of the experiment minimized problems due to 
moisture condensation and dripping. 

(5) The design and routing of flight and GSE cables 
and fluid lines was such that these cables and fluid lines would not 
pose any obstruction to module egress or be subject to damage. 

(6) Where possible in the design of the experiment, 
consideration was given to using captive-type fasteners for internal 
mounting of experiment components, to preclude loss of attachment 
hardware . 


(7) Experiment thermal control subsystems were designed 
so that constant or periodic circulation of fluids was not required 
during periods of power-down or storage, and to provide ease in the 
servicing of fluids including fill, drain, and dry operations. 

c. Electrical Constraints 


(1) Instrumentation system capabilities and sensors 
required to support ground test activities were included in the flight 
hardware wherever practical, in order to minimize the requirements for 
separate ground support equipment, 

(2) Where feasible, pyrotechnic devices were category 
B as defined in GP-469, Explosive Safety Handbook (i.e., "Category B 
electric-explosive devices are those which will not, in themselves or 
by initiating a chain of events, cause injury to people or damage to 
property") . 


B. Ground Support Equipment 


1. General 


a. Onboard monitoring and control of those operations which 
might be hazardous to ground test personnel were capable of being moni- 
tored and controlled by GSE. 

b. GSE required for support of ground testing, monitoring, 
and servicing activities was minimized by making maximum use of the 
flight subsystems to support these functions. GSE related to ground 
servicing Included provisions for external excitation voltage and 
monitoring capability, to preclude the necessity of Internal power-up 
for these activities. 

c. Development testing of GSE was required only when it was 
impractical, impossible, hazardous or not cost-effective to rely solely 
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on an engineering analysis or acceptance verification to establish func- 
tional performance. 

d. Qualfication testing was accomplished on an exception 
basis only, for those items of GSE which could not be qualified by 
analysis or similarity. 

e. Experiment-specific GSE was provided by the ED. This 
GSE was designed to interface with standardized facility support inter- 
faces for power, fluids, etc. 

f. The design of the GSE took into consideration the existing 
facilities' capabilities at the module integration site, launch site, 

and any other users' facilities, as applicable. Every effort was made 
to provide identical sets of GSE for use at the various test locations. 

g. Means were provided for controlled movement of hardware 
that was not easily hand-manipulated (e.g., tracks, guides or other 
restraining devices with spacing and friction controls), to minimize 
the potential of damage to adjacent equipment and hazards to personnel. 

h. The experiments were protected as necessary during all 
handling operations. 

i. Containers for transporting hazardous material had ade- 
quate handles and lids and indicated when they were positively closed. 
Also, easy-to-recognize markings identifying contents, information or 
special handling notes were provided. 

2. Design and Construction . GSE design adhered to known 
state-of-the-art and to the selection of proven parts, materials, and 
processes to the degree practical. The design was restricted to the 
accomplishment of the GSE requirements. 

a. Operation Periods. After adjustment, GSE was designed 
to operate for a period commensurate with the function being performed, 
without requiring readjustment of controls when set for specific opera- 
ting conditions. 

b. Redundant Electrical Circuits. Redundant electrical 
circuits in GSE were not routed through the same connector. 

c. Operating Power. GSE was designed to be compatible 
with the power existing at the facilities to be used. 

d. Racks and Consoles. The design of subassembly racks 
and consoles included entry access for cables and cooling systems that 
were compatible with the facilities in which they were to be used. 
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e. Fluid (Gas and Liquid). The GSE necessary to support 
fluid systems transferred, conditioned and/or stored the fluid suit- 
able for the ultimate system usage. 

Cleanliness ♦ GSE was designed, manufactured, assembled, 
and handled in a manner such that its presence and/or operation in the 
applicable clean areas and flight vehicles would not violate the clean- 
liness levels maintained therein. In cases where GSE was used for the 
transportation, handling or removal of experiments, the GSE was designed 
to provide adequate means of contamination control consistent with the 
cleanliness levels of the module involved. 

g. Test Provisions. GSE was designed so that failure 
within the GSE or interruption of power would not cause failure or 
damage to the flight hardware being tested. Conversely, failure of 
the flight hardware being tested could not cause failure or damage to 
the GSE. 

h. Single Point Failures. GSE was designed so that a 
single point failure would not affect crew or ground personnel safety, 
cause loss of flight hardware, prevent or compromise accomplishment of 
a primary mission objective or cause a launch to be rescheduled. 

Standard Parts. NASA, Air Force -Navy (AN), Military 
Standard (MS) or Joint Air Force-Navy (JAN) standard parts were used 
in GSE wherever applicable. 

j. Corrosion Prevention. Metals used in GSE were of the 
corrosion-resistant type or suitably treated to resist any corrosive 
conditions likely to be met in manufacture, assembly, testing, servic- 
ing, storage or normal service use. 

k* Electromagnetic Interference. Electrical and electronic 
GSE was designed to perform as specified when operating either inde- 
pendently or in conjunction with other equipment with which an elec- 
trical connection was made, or which may have been installed nearby; 
and would not, in itself, be a source of interference which might 
adversely affect the operation of other equipment. GSE was designed 
to meet the requirements and limits of MIL-STD-461. (Reference 
MIL-STD-462). 


1 * Single Point Electrical Grounding. All units (racks, 
consoles, enclosures) using or generating electrical energy were pro- 
vided with an accessible and clearly marked ground stud for single 
point grounding purposes. The DC resistance between any metal part 
of the units (covers, lids, hinged doors, etc.) and the ground stud 
could not be greater than 100 milliohms. 
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3. Maintainability . Maintainability criteria for GSE were 
specified to satisfy the following requirements: 

a. Accessibility. GSE was designed to permit ease of 
access to accomplish maintenance functions, i.e., inspection, servic- 
ing, adjustment, calibration, or repair. Inspection, maintenance or 
test locations were identified and easily accessible. 

b. Disassembly Provisions. GSE was designed to permit 
ready disconnection, removal and replacement of major assemblies or 
components through use of modular construction design principles. 

c. Environmental Requirements. GSE was capable of success- 
fully performing the required functions during or after being subjected 
to the natural and induced environments encountered during each of the 
modes of transportation, handling, operation and storage. 

d. Transportability, Wherever possible, GSE was designed 
to withstand handling and transportation environments without the nec- 
essity of special containers, or the necessity of monitoring critical 
environments to verify that design limits had not been exceeded. 
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EXPERIMENT TESTING 


A, Development Phase 

1. Requirements . Experiment hardware acceptance was contin- 
gent upon prior verification that the end item would meet each technical 
(performance, interface or design) requirement of the applicable EIS. 
Verification could be accomplished either by assessment or by test (or 
a combination of the two). Commonly used assessment methods were: 

o Similarity : Used when it could be shown that the 

article was identical or substantially similar in 
design, manufacturing processes, and quality con- 
trol to another article that had previously been 
qualified to equivalent or more stringent criteria. 

o Analysis : Used in lieu of testing whenever it 

could be shown by generally accepted analytical 
techniques that an article would meet the appli- 
cable technical requirements. 

o Inspection : Used when it could be shown that 

inspection techniques were adequate to assure 
that the article would meet the applicable tech- 
nical requirements. Inspection was used to veri- 
fy construction features, compliance to drawings, 
workmanship, and physical condition of the article. 

o Demonstration : Used when it could be shown that 

demonstration was adequate to assure that the 
article would meet the applicable technical re- 
quirements, Demonstration was used to verify 
such requirements as service and access, handling, 
convenience and ease of operation. 

o Validation of Records : Used when it could be 

shown that records would substantiate manufac- 
turing processes, materials, traceability, or 
test history performance. 
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For case 8 where assessment methods were not applicable, it was generally 
necessary to accomplish verification by testing. Test programs were 
designed to avoid duplication and to require only the minimum tests 
necessary, subject to considerations of hardware criticality and com- 
plexity. The influence of the hardware Criticality Category (see 
Section X) ' was to emphasize verification by test for Category 1 hard- 
ware, by combinations of test and assessment for Category 2, and by 
assessment rather than test (where feasible) for Categories 3 and 4. 

2 . Test Types 

a. Development Tests . Development tests, as neceBsary, 
were performed to acquire data to support the design and development 
process; to verify feasibility of the design approach by evaluating 
hardware performance, design margins and/or failure modes under simu- 
lated or actual environmental conditions; and to provide confidence in 
the ability of the hardware to pass qualification tests by verifying 
selected performance /design requirements. Hardware used for develop- 
ment testing was representative of, but not necessarily identical to, 
the flight experiment hardware. A Development Test Specification was 
prepared by the ED for each development test and submitted for EDC 
review. Test procedures and a report for each development test were 
prepared by the ED and made available at appropriate development mile- 
stones. 


b. Qualification Tests . Qualification tests were per- 
formed to verify that the design met the technical requirements of 
the EXS, assuring operational suitability in the anticipated environ- 
ments. Qualification test hardware was required to be identical in 
configuration and production processing to the flight hardware. A 
Qualification Test Specification and procedures were prepared by the 
ED and submitted for EDC review. A formal report of qualification 
test results was submitted for EDC approval at completion of the tests. 
The qualification test program was to be scheduled such that there was 
sufficient time to allow for possible failures, rework during testing, 
and preparation, review and approval of the final test report, prior to 
acceptance of the flight hardware. 

General requirements for qualification testing were: 

(1) Qualification tests were to be conducted at the 
highest practical level of hardware assembly. 

(2) If qualification tests were to be conducted on the 
entire end item, then acceptance tests were conducted on qualification 
test hardware prior to qualification tests being conducted. 

(3) Sequence of the qualification tests followed the 
same order in which the environments were to be encountered by the 
flight hardware. 
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(4) Tests to determine whether the qualification test 
hardware was performing within specification tolerances were conducted 
after each environmental exposure, and during the exposure period if 
the flight hardware was required to operate in that environment. 

(5) Qualification tests were performed under strict 
control of environments and test procedures. Adjustment or tuning of 
qualification test hardware was not permitted during tests unless it 
was normal for in-service operation. 

(6) Where redundancy in design existed, the qualifica- 
tion tests assured that each redundancy was qualified. 

(7) If the design configuration or manufacturing pro- 
cesses were changed after acceptance tests on qualification test hard- 
ware were initiated, any differences existing between the qualification 
test hardware and the flight and backup hardware invalidated verifica- 
tion and required repeating the qualification test. 

(8) Qualification tests were to be completed prior 
to the delivery of flight or 1 backup hardware. 

(9) Where considered necessary, components of qualifi- 
cation test hardware were disassembled after testing was completed, and 
inspected to determine margins of safety and potential failure modes. 

(10) Types of Test Environments; Humidity; salt fog; 
high temperature (160°F on Sky lab) ; low temperature (-40°F on Skylab) ; 
shock; fungus; positive pressure (for hermetically sealed equipment); 
acceleration; vibration (sinusoidal resonance search, sinusoidial 
cycling, and random vibration); acoustic noise; altitude or space simu- 
lation; and atmospheric compatibility (oxygen, nitrogen, or two-gas en- 
vironment) . 


c. Acceptance Tests. Acceptance tests were conducted to 
verify the performance and configuration of each experiment hardware 
end item at the time of its acceptance by the Government or delivery 
to another NASA center. The ED prepared (subject to EDC review) an 
Acceptance Test Specification, defining the limits and methods for 
each test, and Acceptance Test Procedures based on this specification. 
Data sheets were prepared showing the results of all acceptance tests 
performed. 

General requirements for acceptance testing were; 

(1) Environmental tests were included in acceptance 
tests in instances where a type of manufacturing flaw could not be 
detected by inspection or other nondestructive means. (e.g., conduct- 
ing a vibration test on electronic equipment to find faulty solder 
joints). 



(2) The severity, duration, and number of tests were , 
constrained so as not to result in overstressing or degradation of the 
hardware performance capability. 

(3) Where possible, all normal, alternate, redundant 
and emergency operational modes were tested. 

(4) The hardware was calibrated and aligned prior to 
conducting acceptance tests. 

(5) Acceptance tests were performed under strict con- 
trol of environments and test procedures. Adjustment or tuning of 
hardware was not permitted during acceptance testing unless it was 
normal for in-scrvice operation. 

(6) Any repairs, modifications or replacements after 
completion of acceptance tests required retesting to assure the accept- 
ability of the change. 


B . Integration Phase 

1. Requirements . Integration tests were performed to verify 
those interface requirements that could not be formally verified at 
the individual experiment hardware level. General integration test 
requirements were originally baselined in the ERD, including an ex- 
periment hardware flow diagram from the ED through the module integra- 
tion and launch sites, types of tests at each site and associated spe- 
cial constraints. These requirements and constraints were later ampli- 
fied and updated in the EITRS documents, which reflected concurrence 

of all agencies involved (i.e., the ED, EDC, EIC , Module Development 
Center and Contractor, as applicable). The Module Development Center/ 
Contractor then developed the detailed TCRSD, covering integration 
testing at both module and launch sites. The TCRSDs contained detailed 
requirements for each test, criteria for judging the success of the 
test, and any special constraints. From these detailed requirements, 
the site responsible for conducting the test prepared detailed test 
procedures to satisfy each requirement. At module integration sites, 
satisfaction of the requirements was a constraint on acceptance of the 
module. At the launch site, satisfaction of the requirements was a 
constraint on flight readiness. 

2. Test Types . Normally, all of the following tests (as appli- 
cable) were performed in the initial experiment integration at the module 
site; ideally, only minimal integrated systems testing was performed on 
experiments at the launch site. However, if it was necessary to remove 
an experiment for calibration, maintenance or modification (or if its 
interfaces were otherwise disturbed) at any time after module integra- 
tion, all applicable integration tests had to be repeated prior to the 
launch site integrated systems test. 



a. Receiving and Inspection (R&I) . Whenever hardware 
was delivered to a site, the equipment and its accompanying data pack- 
age were inspected for completeness and any evidence of physical damage. 
The hardware was not actually operated during R&I unless there was an 
indication of physical damage during shipment. 

b. Pre-Installation Tests (PIT). Following R&I, the hard- 
ware was delivered to a clean room (normally class 100,000), where it 
was set up and tested using experiment GSE. Testing was limited to 
that needed either to verify that baseline calibration data remained 
valid or to determine a new data baseline prior to mating the experiment 
to the flight vehicle. This baseline data (collected either during the 
PIT or during the earlier acceptance test at the ED site) was needed 
prior to system testing on board the module for comparison with data 
collected during the module system test, in order to determine the 
effect of module environment (electrical, EMI, etc) upon the experiment. 

c. Functional-Interface Verification Test (FIV). The objec- 
tives of these tests were strictly limited to verification of all inter- 
faces with the module. FIV began with verification of mechanical inter- 
faces by mounting the experiment in the module. If installation of the 
experiment involved a part of the module primary pressure structure, the 
seal of the experiment was leak tested following installation. Following 
mechanical installation in the module, polarity of the module power input 
at the experiment interface was checked. A megger-ohm test was performed 
upon the experiment prior to electrical mating, to verify that the ex- 
periment hardware was properly isolated from the module and that experi- 
ment input impedances met interface requirements. Using a "break-out 
box" between the module power cable and the experiment power connector, 
measured power was applied to the experiment and calculations were made 
to verify the experiment power profile. Following these power checks, 
the power connector was mated directly and the experiment was operated 
under flight conditions (as far as practicality would permit) to verify 
the remaining experiment electrical interfaces. All modes of the ex- 
periment operation were iiot functioned unless an interface was involved 
that would not be tested otherwise. 

d. Integrated Systems Tests. Following successful comple- 
tion of all interface verifications of individual experiments, integrated 
system tests were conducted to verify that experiments and module systems 
could play together without degradation of the performance of either. 
These tests were characterized primarily as electromagnetic compatibili- 
ty tests, and were performed utilizing existing flight plans and check- 
lists, with flight crew participation, to the greatest extent possible. 
The tests were evaluated by comparison of their data with baseline data 
provided by the experiment acceptance and/or PIT tests. 
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